1

To note: I've just implemented fflib and have thus separated TriggerHandler logic from SObject Domain classes. That is, I have (for example) two classes:

  • AccountsTriggerHandler extends fflib_SObjectDomain
  • Accounts extends fflib_SObjects implements IAccounts

Let's say I have a simple method on Accounts:

public void setDescription(fflib_ISObjectUnitOfWork uow) { for(Account a : (List<Account>) getRecords()) { a.Description = 'My Description'; } uow.registerDirty(getRecords()); }

I'm passing in the Unit of Work because I've seen this in several places of sample code for fflib. And, that's all well and good if the calling context is not a Before Trigger. But if it is, the Unit of Work shouldn't be used at all...so do I instantiate one, pass it in, but then never call commitWork()?

I could instead define the method without the Unit of Work parameter and just pass back the list of records so that the Trigger or any other calling context can decide what do to with it. That seems fine for this simple logic, but if there's more complexity within the method logic that requires calling various register methods throughout, that may not suffice. Though, admittedly, this may be an entirely theoretical issue since any such complex logic is unlikely to be needed in both a before trigger and from other calling contexts.

Or, am I just overthinking this and I should define the method now without a Unit of Work since that's what I need right now...then deal with other contexts if/when it's ever needed in the future?

Improve this question
2
  • you are overthinking this; if setDescription should be done only in a trigger context, it should be a method in AccountsTriggerHandler. One would typically use uow in a domain class method if it were being called from a Service layer Commented May 30 at 21:56
  • @cropredy I've just begun to implement fflib, so it's definitely possible I'm misunderstanding. But I have been treating the trigger handler as part of the controller layer, calling the service layer. Should I also maintain a separate set of domain logic in the trigger handler, relevant only to trigger contexts? Commented May 30 at 23:10

1 Answer 1

Reset to default
1

If setDescription is something you want to do only in a trigger context (i.e. on DML of the Account), then the method should be added to AccountsTriggerHandler without the uow argument. This would be typical for before insert / before update contexts where you opted to use Apex to do what can now be done in Fast Save flows

Given that as defined in the OP, the method takes no other args, then it would be unlikely to be called from a service layer using context known to the service. Hence, don't pass the uow argument

Now, if setDescription sometimes depended on data that is not part of the database (yet), then I could see two methods

private void setDescription() { // goes in AccountsTriggerHandler .. set value based on trigger context data (Account and any parents) } // goes in `Accounts.cls` public void setDescription(fflib_ISObjectUnitOfWork uow, MyContext myContext) { .. set value based on values in custom type MyContext, then registerDirty }
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.