Summary

A key task for any domain object mapping framework is to identify the set of
relational data on which to operate. Applications indicate this set using identity
objects. An identity object often corresponds directly to a table's
primary key and as such refers to exactly one row of data. An identity can also
define criteria that match several rows across multiple tables.

The relational concept that is analogous to an identity object is the WHERE
clause in SQL statements. To illustrate the mapping from identity objects
to selections (i.e., WHERE clauses),
reconsider the Product table example given in the introduction
section earlier: An application uses domain objects to access the [Product]
table which contains all products available for sale. The application also uses
two types of identity objects. The first is a simple ProductCode
that is unique for every product. The second is a ProductCriteria
object which defines various optional attributes that are useful for inventory
searches. The following figure illustrates:

The Selection Factory pattern encapsulates the details of translating from
identity objects to WHERE clauses using a factory
object. Since these details are likely to vary among identity objects and target
database entities, you can define factory objects for each translation variation

The following figure illustrates the static structure for the Selection
Factory pattern :

The ISelection interface defines the selection
representation for your system and ConcreteSelection
implements it. If the domain object mapping sits on top of a data accessor, you
can define a selection representation that is independent of any database
platform. In most cases, you simply use strings to represent SQL WHERE
clauses. The ISelectionFactory interface defines a
single method for generating a new ISelection-derived
object
based on an identity object. ConcreteSelectionFactory
implements this interface for a specific identity object type or target database
entity. The overall domain object mapping is likely to require multiple ISelectionFactory
implementations each with customized mapping details encapsulated within each of
them. Client code and any other object mapping infrastructure code refers only
to ISelection and ISelectionFactory
interfaces, keeping them decoupled from any specific mapping details.

The following figure illustrates the sequence diagram for the Selection
Factory pattern:

When a client requires a new Selection object, it
creates an identity object and passes it the ConcreteSelectionFactory.NewSelection
method which in turn creates and returns a ConcreteSelection
object. The client uses this ConcreteSelection
object to issue database read and update operations.

Domain object mapping encapsulation
A selection factory encapsulates the translation of identity objects that
are defined using domain concepts to selections (WHERE
clause) that identify data using data model details.

Isolation of identity object and database entity details
You can define a different selection factory implementation for each type of
translation, keeping them isolated from each other.

Consistent client interface
Selection factory define a consistent client interface that applications and
other middleware code can use generically without requiring references to
specific implementations.

As an alternative to depending on a particular database platform, you can
design ISelection and ISelectionFactory
to use logical database concepts that are defined as part of Data
Accessor implementation.