You need to sign in to do that
Don't have an account?
scottm_p
best practice for controllers
Would be interested on thoughts or links to articles on best practice for apex controllers. My feeling is that they should be as lightweight as possible delegating the functionality to a set of business objects they call.
I don't have any documentation, but I would assert that this is a reasonable design model. A page should only include the necessary logic to render the UI. Logic that directly affects records should be contained in triggers, if possible. For example, if you have a page that allows you to edit opportunity line items, you would probably want to have any calculation methods (such as calculating a custom total) as a trigger.
find the best Practices here
http://wiki.developerforce.com/page/Apex_Code_Best_Practices
Thanks,
Bhup
Thanks for this. I am aware of these but they mostly relate to governor limits. There seems to be relatively little out there about how to structure apps in Salesforce. Much of the code I see is quite basic with little in the way of a proper set of business objects. To me the Salesforce objects are really data objects, I think there should be a proper business layer on top so like this
Salesforce objects (native and custom)
Business Objects
Controllers
Visualforce pages
One convention I use is to create wrapper classes for all my SFDC SObjects that need some sort of APEX. This way, I can give each SObject custom methods. I also use a Gateway class to collect all related SObjects before executing 1x1 validations/derivations on a trigger list - this avoids too many SOQL call governor issues
Here is a trivial example: