Why I need Selector Layer?

[pgajek2]

Hello!

Salesforce provides a default query langue: SOQL. Developers can use it inline in Apex code.
I got the opinion that the "Selector Layer is only an additional complication, and not really needed".

I wonder about the pros and cons of the Selector Layer in Apex.

Considerations:

1. Why use a Selector framework that loads the CPU and reduces Apex Heap Size?

2. Ensure that fields are consistently queried. ~ Salesforce.
   Does it mean that I should query fields even if I do not need them? eg. https://github.com/financialforcedev/df12-apex-enterprise-patterns/blob/master/df12/src/classes/OpportunitiesSelector.cls

3. Additional effort is needed to learn the framework.

4. Long relationships are stored as String e.g Contact.Account.RecordType.DeveloperName. sObjectField cannot be used to do such kind of thing. We are losing field references in the code.

5. The selector class is God Class.

6. The selector class contains a lot of different methods. How to name it?
    public List<Opportunity> selectByIdWithLineItems(Set<Id> recordIds) {}

   1. It's a problem. Names try to mimic what methods do, but sometimes conditions can be really complicated. selectByNameAndRecordTypeWithLineItems(...)

   2. What developers should do? Build query inline to skip methods creation? e.g.
      `new AccountSelector().withFields(...).withWhere(...).execute()`?

I realize, that much depends on Selector implementation.
My concerns based on fflib_SObjectSelector.

PS.: My questions are kind of critical, but I like Selectors, and see a lot of pros to using it. :)

[daveespo]

This topic has been discussed many times -- both publicly and within countless engineering teams.

The short answer to the lengthy discussion is that Selectors promote consistency. That is, without a centralized layer to access your data, inconsistencies can creep into your application because different conditions are used for filtering records. And, in the Salesforce case, you retrieve different "shapes" of records (different fields are selected) and find yourself with runtime bugs when fields are accessed without being explicitly queried for. Fowler's Enterprise Patterns book is a good read if you are looking for the non-Salesforce explanation: https://martinfowler.com/eaaCatalog/tableDataGateway.html

To answer your bullet points in order:

1. Because CPU and Heap Size are usually not material considerations for most application execution paths. Sure, you might need to tune a specific hotspot, but don't preoptimize for performance at the expense of maintainability.

2. Basically, yes. You define your "common case" shape of an SObject. As the Trailhead docs indicate, you don't include things that are uncommonly used or expensive to carry around (long text fields, for example)

3. You have the benefit of Trailhead and Andy's book to train up your engineering staff on AEP. If you build your own "framework", there's a different kind of learning curve with homespun documentation. Neither one is free.

4. I'm not sure what you're concerned with here. If you're saying you're losing compile-time type safety for relationship references, yes, you are.

5. Not sure if there's a question there.

6. Refer back to what I wrote earlier. Having every every developer write the most lean query for their specific story will result in duplicate code or, more likely, inconsistent code. Set aside the concern for memory optimization early on and come back later to tune known hotspots. You can overload methods with extra arguments to cover more elaborate filtering needs -- but yes, you'll want methods like selectByName(Set<String> name) and selectActiveById(Set<Id> idSet) and selectRecentlyEdited(Integer limit).

[cropredyHelix]

I'll add one additional (IMHO, huge) benefit:

Selector classes enable you to mock their return values in unit tests. For example, the apexmocks framework is nicely folded into the AEP framework. The 3rd edition of Fawcett's book, chapter 12, gives examples

• When you mock selectors in testmethods, you don't have to DML any records for that test and can focus on testing the service, controller, invocable, domain or batchable/queueable execute() business logic using a wide array of mocked SOQL results. This is often done in conjunction with mocking the unit of work (thereby avoiding DML time in your testmethod).

• Selectors on un-DML insertable-in-testmethod objects are especially useful (like CronTrigger, AsyncApexJob, etc) - so you can mock the results (using the JSON serialize/deserialize technique or libraries that exploit that such as Sobject Fabricator. Mocked selectors also provide a way around SeeAllData=true in some use cases.

To @daveespo answer to #1, 100% agree. The computer is meant to be our servant and let it burn electrons rather than the developer burning neurons; optimizing only when needed. I love the consistency that every query is wrapped in a selector, even if initially it takes me a bit longer to set them up.