Update: Dreamforce is over for another year! Thanks to everyone who supported me and came along to the session. Salesforce have now uploaded a recording of the session here and can find the slides here.
As part of this years Dreamforce 2013 event I will be once again running a session on Apex Enterprise Patterns, following up on my recent series of developer.force.com articles. Here is the current abstract for the session, comments welcome!
Building Strong Foundations: Apex Enterprise Patterns “Any structure expected to stand the test of time and change, needs a strong foundation! Software is no exception, engineering your code to grow in a stable and effective way is critical to your ability to rapidly meet the growing demands of users, new features, technologies and platform features. You will take away architect level design patterns to use in your Apex code to keep it well factored, easier to maintain and obey platform best practices. Based on a Force.com interpreation of Martin Fowlers Enterprise Architecture Application patterns and the practice of Separation of Concerns.” (Draft)
I’ve recently started to populated a dedicated Github repository that contains only the working sample code (with the library code in separate repo). So that i can build out a real working sample application illustrating in practical way the patterns in action. It already covers a number of features and use cases such as…
- Layering Apex logic by applying Separation of Concerns
- Visualforce controllers and the Service Layer
- Triggers, validation, defaulting and business logic encapsulation via Domain layer
- Applying object orientated programming inheritance and interfaces via Domain layer
- Managing DML and automatic relationship ‘stitching’ when inserting records via Unit Of Work pattern
- Factoring, encapsulating and standardising SOQL query logic via Selector layer
The following are ideas I’ll be expanding on in the sample application in preparation for the session…
- Batch Apex and Visualforce Remoting (aka JavaScript callers) and the Service Layer
- Apex testing without SOQL and DML via the Domain Layer
- Exposing a custom application API, such as REST API or Apex API via Service Layer
- Reuse and testing SOQL query logic in Batch Apex context via Selector Layer
- Rich client MVC frameworks such as AngularJS and Service Side SOC
What do you think and what else would you like to see and discuss in this session?
Feel free to comment on this blog below, tweet me, log it on Github or however else you can get in touch.
Andy in the Cloud 
September 16, 2013 at 3:32 pm
Andy,
One thought that I had would be a comparison of when to use simple EAA patterns and when to use the more involved patterns.
For example, the typical developer in SFDC likes to cram everything into a page controller and go from there. They put query code in there. They put logic code in there. They even throw the “kitchen sink” in there on occasion.
All too often, it reminds me of Martin Fowler’s description of the Transaction Script pattern. (http://martinfowler.com/eaaCatalog/transactionScript.html). Fowler’s book talks about the pros and cons of using that pattern verses a Domain Model pattern like you have talked about in this series. I get the impression from younger developers that they look at EAA patterns and ask themselves the question, “Why should I bother investing in this stuff?” I know you have definitely touched on the “Why’s” before, but it is always something that can be reviewed and continually taught. As these developers get more experience (and make the mistakes), they are more open to these types of patterned approaches.
I think it would be a great topic for the talk to discuss the “WHY and WHEN” someone would choose the simplest of patterns verses when it makes sense to really invest some time and setup the more complex patterns. Using real world examples of both sides of the discussion will help.
Another thought might also be to express to the audience that Apex is not any different than the more mature languages out there like Java, Ruby and .NET. Apex is maturing and it does/can/will benefit from learning the “wisdom” from these types of patterns and approaches like Java/Ruby/.NET and other languages have benefited from over the years. As Apex starts to better support the more advanced operations out there (like true Reflection support), this will only get more true.
Also weaving in more of the thought process of SOC and DRY in these talks would help developers better understand the “Why”. Your blog on SOC was fabulous and these types of thoughts continually need to be reviewed.
Anyway, this is just my “two cents” on the subject …or “0.01 Pound Sterling” ;-). I hope this helps and can’t wait to hear the talk.
All the best.
Cheers,
John
September 19, 2013 at 1:34 pm
John, totally agree, much appreciated your time to give this feedback, will dial up the messaging and illustrations on the why for sure, thanks!
October 1, 2013 at 11:00 pm
Andy, as a want-to-be developer but more importantly a product manager for a potential force.com product (and eventually series of products), I’m finding lots to keep coming back to on your recent posts & code Thanks for taking the time to share with the community. Can’t wait to see the video of the DF13 session.
October 2, 2013 at 11:04 am
Your very welcome, really appreciate the kind and motivating feedback!
April 4, 2014 at 7:03 am
Thank you some for this work Andrew. I use it in more and more projects. Having centralised SOQL Builders is of immensive use.
But not being able to query parent fields limits its usage in enterprise apps very much
This doesn’t compile
public List getSObjectFieldList() {
return new List {
ChildRecord__c.Name,
ChildRecord__c.Parent__c,
ChildRecord__c.Parent__r.GranParent__c
};
}
This compiles but doesn’t query the defined fields:
public List getSObjectFieldList() {
return new List {
ChildRecord__c.Name,
ChildRecord__c.Parent__r.Id,
ChildRecord__c.Parent__r.GranParent__r.Id
};
}
I created a GitHub issue for that:
https://github.com/financialforcedev/df12-apex-enterprise-patterns/issues/6
April 4, 2014 at 4:32 pm
Your very welcome Robert, thanks for raising the issue on GitHub, i’ve migrated it to the main GitHub repo (we retired the DF12 one as the patterns become more popular and we wanted to split out the sample code). See here to continue the chat! https://github.com/financialforcedev/fflib-apex-common/issues/4
Pingback: Episode 3 – Andrew Fawcett on Enterprise Development | Code Coverage