Proposals for adding a Criteria Builder to Apex Enterprise Patterns (FFLIB)

[daveespo]

Over the past several years, several members of the community have requested the addition of a “criteria builder” to the FFLIB Apex Common project. See Issue#292 and Issue#476

Some extremely generous people have even proposed pull requests with fully functional implementations of such functionality – See PR#458, PR#393 and PR#313

We took a long and thoughtful look at all of the proposals. We spent time trying to be an “end user” of the implementations by trying to model various criteria scenarios. We also built our own implementation of a criteria builder that addressed some of the concerns we had with the ones enumerated above. In the end, we have decided not to integrate a “criteria builder” into FFLIB.

The core concern kept coming back to “why?” – Some of the proposals were trying to address type safety and SOQL injection. Some were trying to implement “SOQL-esque” filtering with in-memory SObjects as part of the Domain layer. Some directly addressed the legacy and “new” bind variable support. Some addressed the SOQL built-in ‘literals’ (the LAST_N_DAYS:x functions). Some were very expressive with modeling every comparison operation as its own Apex method; others used a “operand - operator - literal” approach. Some wanted to have ‘reusable’ criteria clauses.

By the time we got done considering every Swiss Army knife use case, we realized that we would have a huge amount of new code and would likely do a disservice to some of the use cases that people were holding out hope for.

Instead, we found that we had a very expressive way to compose filtering criteria: SOQL. Seriously though, SOQL is concise, easily readable, and doesn’t hide under layers of Apex. In most of the cases, we saw that each line of a “WHERE clause” turned into 3-10 lines of Apex. It made the intent of the author less clear at a glance.

Adding significant code complexity for mixed benefit is a consideration that we weigh with each PR that is submitted. We thank those that have provided thoughts and reviewed the existing PRs. We will be closing out the existing PRs as wontfix – please don’t consider that an indication of the quality of the work – each of the authors spent a lot of time producing a large body of quality work and we thank them for offering their solution for consideration.

[wimvelzeboer]

It makes sense, and I agree with your decision. I think if people want to have a builder pattern then they should be able to implement it on top of the current selector, just specific for those use cases.

I however ran into multiple cases that I had to clone the selector/queryfactory class for adding some small changes, because I wasn't able to override certain bits of the selector/queryfactory.

Now that this decision is made, would it be an idea to review the selector and queryfactory class, to make sure it fully flexible/extendable? Like that you take the max in adding virtual methods and protected variables?

[ImJohnMDaniel]

@wimvelzeboer, if you have suggestions, please put them forth. I would recommend that we setup an issue first and discuss verses opening a PR prematurely.

I guess one thought that I have is why would you need to modify the FFLIB_SObjectSelector class? Would you not simply make use of your custom criteria builder class within the Selector method?

[wimvelzeboer]

This PR is one example: #464