Take a look at the implementation of the selectSObjectById base class method we have been using so far in this chapter. The following buildQuerySObjectById method code gives us an indication of how we implement custom Selector methods; it also highlights the newQueryFactory base class method usage:

public List<SObject> selectSObjectsById(Set<Id>idSet) { 
  return Database.query(buildQuerySObjectById()); 
} 
private String buildQuerySObjectById() { 
  return newQueryFactory(). 
           setCondition('id in :idSet'). 
           toSOQL(); 
} 

The newQueryFactory method exposes an alternative object-orientated way to express a SOQL query. It follows the fluent design model with its methods, making code less verbose. For more information on this approach, see https://en.wikipedia.org/wiki/Fluent_interface.

The instance of fflib_QueryFactory returned by this method is preconfigured with the object, fields, order by, and any field set fields expressed through the selector methods discussed previously. As described earlier, it will also enforce security enabled. So, in general, all you need to do is provide a SOQL where clause via the setCondition method, as shown in the preceding code. Finally, the toSOQL method returns the actual SOQL query string that is passed to the standard Database.query method.

The fflib_QueryFactory class methods provide an alternative to using the standard string concatenation or String.format approach when building dynamic SOQL queries. The original author of the fflib_QueryFactory class, Chris Peterson, was motivated in creating it to avoid the fragility that string-based methods can give, as well as to provide a more readable means to understand what such code was doing. In addition to this, because the class supports using SObjectField references as opposed to field name references in strings, such code is less prone to SOQL injection vulnerabilities.