0

As I understand it a selector would be implemented for each SObject that you need it for i.e

  • AccountSelector extends fflib_SObjectSelector {}
  • ServiceAppointmentSelector extendes fflib_SObjectSelector {}

Is the idea for all queries related to account be associated with AccountSelector class? This makes sense for queries that are often used i.e. new AccountSelector().selectByIds() or new AccountSelector().selectByCaseId().

One of the situations I'm sure is common is a query on accounts but is very specific say to a Controller class for an LWC or a query that would only ever be used in batch class.

It makes more sense for these one off queries to live in the controller or the batch class where they are used and not inside of the AccountSelector class.

What are patterns that are used to accomplish this without duplicating code? A couple ideas I had are that I'm not sold on are:

Create the custom query in AccountSelector

  • Pros: Class already exists, no need to extend or create a new class that extends fflib_SObjectSelector
  • Cons: Query will only ever used in controller. Makes more sense for it to live in the controller. AccountSelector class becomes coupled with the controller class.

In the controller class have an inner class that extends AccountSelector.

  • Pros: No need to specify the sobject type and fields that are required.
  • Cons: Extending the class is overkill. Only the custom query would be used.

In the controller simply create a new inner class that extends fflib_SObjectSelector

  • Pros: No need to extend, only contains the custom query(ies) needed for the controller
  • Cons: Need to specify the object type and fields which may be a duplicate of the field list in AccountSelector

1 Answer 1

1

I haven't used the fflib apex enterprise patterns in any of my projects, so take that into consideration with my answer.

To me, the big points of using the enterprise patterns (of which SObjectSelector is one piece) are:

  • Separation of concerns
    • I'd argue this makes things more of a pain to use, but it makes things easier to test
    • Also sets you up to be able to write tests (for things that use the selector, at least) that don't require DML and queries (which slow down test execution) by mocking the selector or some other method where you can specify in-memory values to return for your test
  • Treating queries as logic, and keeping queries for a given base object in a single location
    • Helps people know where to look for information/changes

Selectors also give you a single point of control when it comes to enforcing CRUD/FLS.

So having some queries in the selector, but others embedded inside of batch/controller classes defeats some of the purpose here.

If I recall, the fflib SObject Selector allows you to do something like define your own methods that run different queries or pass a list of fields (via a fieldset?) in to query. As such, the preferred approach is likely to be to just keep adding custom query methods to the selector.

I suppose you could also create a separate Apex class to extend an existing selector if things get too unruly or if it would help for purposes of packaging. The main point is that if you're going to use the Selector pattern, it's probably a good idea to do your best to maintain the separation between the various layers (Selector, Service, and Domain). To that end, making inner classes in your controller would defeat the purpose.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .