Apex is a very expressive language to perform calculations and transformations of data entered by the user or records read from your Custom Objects. However, SOQL also holds within it a great deal of expressiveness to select, filter, and aggregate information without having to resort to Apex. SOQL is also a powerful way to traverse relationships (up to five levels) in one statement, which would otherwise leave developers on other platforms performing several queries.
Quite often, the same or similar SOQL statements are required in different execution contexts and business logic scenarios throughout an application. Performing these queries inline as and when needed, can rapidly become a maintenance problem as you extend and adapt your object schema, fields, and relationships.
This chapter introduces a new type of Apex class, the Selector, based on Martin Fowler's Mapper pattern, which aims to encapsulate the SOQL query logic, making it easy to access, maintain, and reuse such logic throughout the application.
The following aspects will be covered in this chapter:
- Introducing the Selector layer pattern
- Implementation design guidelines
- The Selector class template
- Implementing the standard query logic
- Implementing the custom query logic
- Introducing the Selector factory
The following is Martin Fowler's definition of the Data Mapper layer on which the Selector layer pattern is based (http://martinfowler.com/eaaCatalog/dataMapper.html):
"A layer of Mappers (473) that moves data between objects and a database while keeping them independent of each other and the Mapper itself."
In Martin's definition, he is referring to objects as those resulting from the instantiation of classes within an OO language such as Java or Apex. Of course, in the Force.com world, this has a slightly ambiguous meaning, but is more commonly thought of as the Standard or Custom Object holding the record data.
One of the great features of the Apex language is that it automatically injects object types into the language that mirror the definition of the Custom Objects you define. These so-called SObjects create a type-safe bond between the code and the database schema, though you can also leverage Dynamic Apex and Dynamic SOQL to change these references at runtime if needed.
Essentially, SObjects are the native in-memory representation of the data read from the database. Thus, a traditional Plain Old Java Object (POJO) approach in Apex is not strictly required to expose the record field data. Additionally, through relationship fields such as Race__c.Drivers__r, related records can be accessed without the need for the usual POJO relationship accessor methods or properties.
For this reason, the role of Apex classes that represent the Selector layer code described in this chapter is much more focused on encapsulating the application's SOQL queries, promoting reuse and data consistency rather than mapping information from the database into memory.
Note
One might consider the Domain classes as data wrappers around SObject, as they contain a list of SObjects. However, this is not the intent; the Domain class methods purely expose behavioral methods. The Records property exposes the SObject list so that callers can access the field data in the usual manner.
The following diagram illustrates where Apex classes implementing the Selector layer fit in terms of its interaction and reuse within the Service and Domain layers as well as other execution contexts such as Batch Apex. For the most part, it is a layer that exists conceptually below the Service layer (under the Service boundary), though it can be reused from execution contexts that perform database queries, such as Batch Apex and Controllers.
