With USER_MODE - do we still need SOQL and DML libs?

Question

As the Security model of Apex was leaky in the past, everybody who took - or as AppExchange Partners had to take - Security seriously was building or using libraries to enforce CRUD/FLS rules. The most notable among them is the FinancialForce FFLIB or Patron DmlManager.

When stripInaccessible(), WITH_SECURITY_ENFORCED and USER MODE where initially piloted, I already asked this question and there where many skeptics that they would finally end the need for clunky libraries.

But hey, isn't that exactly the goal of Salesforce? To make our and their lives easier when writing and reviewing Apex code.

So my Questions are:

1. Why do you think we can / can't replace SOQL Builders with User Mode SOQL?
2. Why do you think we can /can't replace DML Managers with User Mode DML?

Answer 1

Why do you think we can / can't replace SOQL Builders with User Mode SOQL?

I will answer your first question because I have more experience with Selectors which gives me a better view of why we need them.

First of all WITH USER_MODE applies an FLS + Sharing rules to the SOQL:

The object permissions, field-level security, and sharing rules of the current user are enforced.

Of course, it's a good practice to do it, but we do not live in a perfect world, a lot of projects have bad design. What if I would like to respect FLS, but get records without sharing to meet business requirements? WITH USER_MODE is not always a solution.

Secondly WITH USER_MODE covers a tiny fraction (FLS, sharing rules*) of what Selectors can do.

There are a lot of benefits that the Selector layer can provide:

1. Additional level of abstraction - The selector layer is an additional level of abstraction that gives you the possibility to control the execution of SQOL. It's a quite generic statement, but that level is a source of other benefits.
2. Mocking - Selector classes give a possibility to mock return values in unit tests.
   • Mock external objects (__x) - External objects cannot be inserted in unit tests. You need to mock all SOQLs, of course, there is if (Test. isRunningTest()), but not an elegant and clean solution.
   • Mock custom metadata - Custom metadata cannot be inserted in unit tests unless the developer uses the Metadata API. Mocking can be a solution.
3. Control field-level security - The best practice is to execute SOQLs WITH USER_MODE to enforce field-level security and object permissions of the running user. The selector layer can apply WITH USER_MODE by default to all of the queries, so the developer does not need to care about it. Developers can also add WITH SYSTEM_MODE to all SOQLs from a specific selector. I believe selectors make FLS control easier.
4. Control sharings rules - The selector allows to execution of different SQOLs within the same class in different sharing modes (with sharing/without sharing).
5. Avoid duplicates - Generic SQOLs like getById, and getByRecordType can be stored in the selector class. It makes developers' lives easier when you have predefined/tested methods.
6. Default configuration - The selector class can provide default SOQL configuration like default fields, FLS settings, and sharing rules. I was on a project were sharing rules were screwed up and each SOQL needed a default condition OwnerId = :UserInfo.getUserId(), it was quite simple to achieve with Selectors by adding a default condition to all of the SOQL.
7. Cache - The selector can have additional logic to save SOQL results. That approach can be beneficial in places where we need to save SOQL limits.

SOQL Lib

• SOQL Lib (github)

Resources:

• Apex Enterprise Pattern - Advantages Of Selector Layer
• https://github.com/apex-enterprise-patterns/fflib-apex-common/discussions/432

Answer 2

Good answers already given for the advantages of selector layer. I think the selector layer is one level of abstraction above the SOQL builder, it can be used with native SOQL to achieve the same advantages without a SOQL builder. Selectors and builders are little different.

The advantages of SOQL builder itself can be:

1. Enable reuse of SOQL statement fragments, such as where condition, and compose them with different criteria.
2. When SOQL contains date and currency literals, we can only use dynamic SOQL with string concatenation to inject the values. This will fail: [SELECT Id FROM Account WHERE AnnualRavenel > USD:amount].
3. With SOQL builder we can enhance its features, such as introduce new comparison operators like between(Account.AnnualRavenel, 100, 500).

The following demo built with ApexQuery library which supporting run(AccessLevel.USER_MODE) as well.

List<Id> accountIds = ... ;
String countryName = 'United State';
Decimal minAmount = 100;
Decimal maxAmount = 500;

List<Account> accounts = (List<Account>) Query.of(Account.SObjectType)
    .selectBy(Account.Name, Account.BillingCountry, Account.BillingState)
    .selectBy(FORMAT(CONVERT_CURRENCY(Account.AnnualRevenue)))
    .selectBy('Contacts', Query.of(Contact.SObjectType).selectBy(Contact.Name))
    .filterBy(andx()
        .add(inx(Account.Id, accountIds))
        .add(between(Account.AnnualRevenue, USD(minAmount), USD(maxAmount)))
        .add(eq(Account.BillingCountry, countryName))
    )
    .orderBy(Account.AnnualRevenue).descending().nullsLast()
    .run(AccessLevel.USER_MODE);

Resources:

• Advantages of Using SOQL Builder in Salesforce (medium link)
• Apex Query (the github link)

Answer 3

Piotr's excellent answer covers all of the benefits of "SOQL builders". Like he says, their purpose is far more than just to enforce CRUD and FLS.

As for "DML Managers" -- there is still advantage to having a single point of abstraction for some of the same reasons (mocking, auditing/logging, Exception handling, etc.).

With regard to DMLManager -- the actual guts of DMLManager are due to be replaced with the new native Database.insert/update/delete that enforce CRUD/FLS. All of the heavy lifting that DMLManager did to detect "diffs" can now be removed to save CPU and the extra SOQL query. I just haven't gotten around to it yet :-)