Figure 1.2 illustrates the static structure of the Data Accessor pattern. The DataAccessor interface defines the data access abstraction in terms of logical operations that the application code uses. You must define these operations to be extensive enough so that applications can do useful work without forcing applications to use unnatural constructs or workarounds. You can tailor the exact logical operation semantics to keep application code as straightforward as possible. You must also be careful not to expose any physical semantics in these logical operations. Doing so enables application code to depend on exposed physical features, making it difficult to change later. Also be mindful that you do not need to define the entire set of logical operations in a single interface as Figure 1.2 shows. It is common to separate logical query, update, result set, and transaction operations into multiple interfaces.
Figure 1.2. The static structure of the Data Accessor pattern.
ConcreteDataAccessor provides the implementation of logical operations in terms of physical database operations. This class depends directly on specific database technology. You may define more than one concrete implementation if you need to support different physical database interfaces or technologies.
Notice that this pattern encapsulates an application's data access, but it does not encapsulate its data model.