The Enterprise Patterns on a Diet
Not too long ago I wrote a post regarding Andy Fawcett's book, Force.com Enterprise Architecture, though I must confess it's only in the last few weeks that I've really been getting to grips with the patterns and putting them to use.
[
Shying Away
One reason I never really looked into the patterns in too much detail (until the arrival of the aforementioned book) is that I like things to be lean, and simple, I'm not a huge OO guy and the idea of having extra classes around was not something I liked the sound of. I recently started working on a new project and thought it'd be a great chance to put the patterns to use, so I headed to the GitHub repo and was slightly taken aback at how much code was required just to be able to use the base pattern classes, i.e. the Selector, Domain and Service base classes.
Lightening The Load
I raised my concerns over the amount of code required to start using the patterns, and we had a Skype chat to discuss the idea of breaking down the fflib-apex-common library, to remove the dependency on the Apex Mocks library (fflib-apex-mocks) and separate out the more 'advanced' features of it.
Work is still on-going and I've not gotten around to working out how the extras would be bolted on yet, but if you want to get going with the core library then please check out my branch of fflib-apex-common and let me know what you think. So far it's been reduced down to the following classes (plus their respective test classes!):
| Class | Description |
|---|---|
| fflib_SObjectDomain.cls | The Domain layer base class |
| fflib_SObjectSelector.cls | The Selector layer base class |
| fflib_SObjectUnitOfWork.cls | The Unit of Work implementation |
| fflib_SecurityUtils.cls | Utilities for checking CRUD and FLS access |
| fflib_StringBuilder.cls | Utilities for compiling string-based queries etc., the 'light' version of Query Factory |
I'm not going to delve into the details of these classes here as that's what the book is for (or the excellent series of blog posts from Andy on developer.salesforce.com, but hopefully the names are familar and the idea is to distil things back down to the essence of the patterns. With these classes and tests you can start building out your code using these techniques, and so far I'm finding them both beneficial and enjoyable. The use of the service layer in particular is great for keeping your Visualforce controllers simple and free from business logic, as can be seen in these two methods that I wrote today:
@RemoteAction
global static Boolean assignUserToEvents(Id userId, List<Id> events)
{
return EventService.assignUser(userId, new Set<Id>(events));
}
public void schedule()
{
ProjectService.Schedule(new Set<Id>{project.Id});
loadProject();
}
Working With The Patterns
So far I do have more classes than I'd ever have had before just to support a single Visualforce page and single trigger, but there's more functionality to come and I can already see that when I get to that a lot of the core will have been taken care of for me. The Unit of Work is also proving to be an invaluable tool which you could even adopt on it's own if you're not yet ready to take the plunge into using the rest of the patterns available. Trust me, if I can be converted, then so can you.