The Selector pattern provides a powerful layer of encapsulation for some critical logic in your application. It can help with enforcing best practices around security and provides a more consistent and reliable basis for code dealing with the SObject data.

Selectors can also take on the responsibility and concern for platform features such as Multi-Currency and Field Sets. Ultimately allowing the caller—be that the Service, Domain, or even Apex Controllers, or Batch Apex—to focus on their responsibilities and concerns, this leads to cleaner code which is easier to maintain and evolve.

With the introduction of the Selector factory, we provide a shortcut to access this layer in the form of the Application.Selector.selectById and Application.Selector.newInstance methods, opening up potential for more dynamic scenarios such as the compliance framework highlighted in the last chapter.

I'd like to close this set of chapters with a simple but expressive diagram that shows how the Service layer code turns with the help of the Domain and Selector layers. These three patterns on Force.com help add value to the developer through consistency and also support best practices around bulkification and code reuse.

While this is the last chapter focusing on a Force.com implementation of Martin Fowler's Enterprise Application Architecture patterns, we will revisit the role of the Selector in a later chapter and focus on Batch Apex as well as continuing to leverage our Service layer in later chapters that discuss the application integration.