Comments on: Apex Architecture

By: Gary B

Gary B — Thu, 10 Sep 2009 08:26:19 +0000

Just stumbled across this blog and read the last 2 posts – interesting stuff! Adding you to my iGoogle page

I largely agree with your summary at the end. I actually find a lot of my headaches come from managing the lifecycle of workflows and triggers. Trigger fires and makes updates, workflow fires on updates which causes the trigger to fire again. I plan on blogging on this stuff myself but busy winning work right now, but if there’s material already out there, I’d welcome any pointers!

By: Mike Leach

Mike Leach — Wed, 09 Sep 2009 04:57:12 +0000

I’m guessing “class proliferation” is related to “atomicity” in OO design, and most complex domains need to be atomic (ie lot’s of classes) to be maintainable.

I use the 500 line rule to determine when a class should be refactored into 2 (or 3).

In addition to George’s comment, I would also add the (unspeakable) suggestion of relaxing unit test coverage. Not all objects serve a mission critical purpose or modify persisted data.

By: Steve

Steve — Tue, 08 Sep 2009 22:13:43 +0000

Thanks George! I know the product folks have some killer Dreamforce sessions on tap addressing design and architecture. It should be great as always.

By: George Scott

George Scott — Tue, 08 Sep 2009 22:06:22 +0000

Another good post. Maybe dreamforce needs an apex/visual force design patterns session with input from the community as well as sfdc folks. A couple quick thoughts.

I don’t go quite as minimal as you are suggesting in the triggers I write. I mostly pull logic out of trigger and into a class or static method to make it easier to test, reuse code, or enhance code “readability”. But often testing is the main consideration. It is sometimes easier to get complete code coverage by attacking individual functions rather than testing at the trigger level.

The fourth question, class proliferation is a real problem in Apex, and something salesforce should address asap. They really need a proper package/folder hierarchy to organize classes. Sometimes I will use nested classes to get some form of encapsulation to keep related classes “grouped” together rather than place a lot of classes at the “root” level. But this does have its own challenges as well.

By: Steve

Steve — Tue, 08 Sep 2009 19:48:03 +0000

My most complex use cases have had to do with Opportunities and related processes. In my old gig we had to do custom rollups, so to get them right you really have to catch all cases.

It seems whenever revenue is involved, things get complex quick.

By: Mike Leach

Mike Leach — Tue, 08 Sep 2009 19:45:30 +0000

I haven’t yet had a real-world need for a Trigger that handles so many states, so a minimalist design was usually built-in.

What is a common use case that forces this level of refactoring? I’m guessing it’s Opportunity management (?)

-Mike

By: Steve

Steve — Tue, 08 Sep 2009 19:20:46 +0000

Thanks Johan! I’ve been moving away from logic-heavy triggers for quite a while. Refactoring a working code base is always low on the priority list!

By: Johan Liljegren

Johan Liljegren — Tue, 08 Sep 2009 19:04:28 +0000

Excellent, as always. Thanks for your thoughts.
I started thinking about moving logic out of triggers a while back, but haven’t assembled the energy or time to set it off. This post had me thinking again. =)