Over the years I have worked with and for Alfresco, I have written a ton of Alfresco extensions. Some of these are for customers, some are for my own education, some for R&D spikes, etc. I’d like to share a common pattern that comes in handy. If you are a super experienced Alfresco developer, this article probably isn’t for you. You know this stuff already!
The Service Action Pattern
Let’s start by describing the Service Action Pattern. In this pattern, we take the functionality that we want to make available to Alfresco and we wrap it in a service object. This is a well established pattern in the Alfresco world, used extensively in Alfresco’s own public API. Things like the NodeService, ActionService, ContentService, etc all take core functionality found in the Alfresco platform and wrap it in a well defined service interface consisting of a set of public APIs that return Alfresco objects like NodeRefs, Actions, Paths, etc, or Java primitives. The service object is where all of our custom logic lives, and it provides a well defined interface for other objects to use. In many ways the service object serves as a sort of adapter pattern in that we are using the service object to translate back and forth between the types of domain specific objects that your extension requires and Alfresco objects. When designing a new service in Alfresco, I find it is a best practice to limit the types of objects returned by the service layer to those things that Alfresco natively understands. If your service object method creates a new node, return a NodeRef, for example.
I hope this helps you build your next awesome Alfresco platform extension, I have found it a useful way to implement and organize my Alfresco projects.