Sok van a Fowler könyvben is ismertetve. Itt ez részletesebben és koncentráltan van szó. Persze az ördög a részletekben rejtőzik. Itt vannak a témák.
Decoupling Patterns
Decoupling patterns describe strategies for decoupling data access components from other parts of an application. This decoupling allows flexibility when choosing an underlying data model, as well as when making changes to the overall data access strategies for a system.
Another essential aspect to decoupling patterns is the data access abstraction they expose to the rest of the system. This abstraction must be sufficiently versatile to expose the appropriate level of data access capabilities. However, it must also be broad enough to make it feasible to plug in alternate data sources and algorithms. All of the patterns in Part 1, "Decoupling Patterns," work toward these goals.
Data Accessor (9)— Encapsulates physical data access details in a single component, exposing only logical operations. Application code maintains knowledge about the underlying data model, but is decoupled from data access responsibilities.
Active domain object (33)— Encapsulates the data model and data access details within relevant domain object implementations. Active domain objects relieve application code of any direct database interaction.
Object/relational map (53)— Encapsulates the mapping between domain objects and relational data in a single component. An object/relational map decouples both application code and domain objects from the underlying data model and data access details.
Layers (75)— Stack orthogonal application features that address data access issues with increasing levels of abstraction.
Resource Patterns
Resource patterns describe strategies for managing the objects involved in relational database access. A substantial amount of relational database access code today employs a standard call-level interface like Open Database Connectivity (ODBC), Object Linking and Embedding Database (OLE DB), and JDBC. Interface standards have matured in recent years, but most retain well-known concepts like database connections, statement handles, and operation processing. The patterns in Part 2, "Resource Patterns," address performance and semantic issues that frequently arise when accessing relational data using a call-level interface.
Resource Decorator (103)— Dynamically attaches additional behavior to an existing resource with minimal disruption to application code. A resource decorator enables the extension of a resource's functionality without subclassing or changing its implementation.
Resource Pool (117)— Recycles resources to minimize resource initialization overhead. A resource pool manages resources efficiently while allowing application code to freely allocate them.
Resource Timer (137)— Automatically releases inactive resources. A resource timer alleviates the effect of applications or users that allocate resources indefinitely.
Resource Descriptor (159)— Isolates platform- and data source-dependent behavior within a single component. A resource descriptor exposes specific platform idiosyncrasies that relate to particular database resources as generic, logical operations, and enables the majority of data access code to remain independent of its physical environment.
Retryer (171)— Automatically retries operations whose failure is expected under certain defined conditions. This pattern enables fault tolerance for data access operations.
Input/Output Patterns
Part 3, "Input/Output Patterns," describes patterns that simplify data input and output operations using consistent translations between relational data in its physical form and domain object representations.
Selection Factory (191)— Generates query selections based on identity object attributes.
Domain Object Factory (203)— Populates domain objects based on query result data.
Update Factory (215)— Generates update operations based on modified domain object attributes.
Domain Object Assembler (227)— Populates, persists, and deletes domain objects using a uniform factory framework.
Paging Iterator (253)— Iterates efficiently through a collection of domain objects that represent query results.
Cache Patterns
Cache patterns address solutions that reduce the frequency of data access operations by storing common data in a cache. These patterns usually cache domain objects rather than physical data. This is an important design point because it optimizes the cached form that the caller requires. The patterns in Part 4, "Cache Patterns," provide structures for generic, efficient, and extensible caching.
Cache Accessor (271)— Decouples caching logic from the data model and data access details.
Demand Cache (281)— Populates a cache lazily as applications request data. A demand cache is useful for data that is read frequently but unpredictably.
Primed Cache (291)— Explicitly primes a cache with a predicted set of data. A primed cache is useful for data that is read frequently and predictably.
Cache Search Sequence (305)— Inserts shortcut entries into a cache to optimize the number of operations that future searches require.
Cache Collector (325)— Purges entries whose presence in the cache no longer provides any performance benefit.
Cache Replicator (345)— Replicates operations across multiple caches.
Cache Statistics (361)— Record and publish cache and pool statistics using a consistent structure for uniform presentation.
Concurrency Patterns
Concurrency patterns address what happens when multiple users issue concurrent database operations that involve common data. Most databases include locking features to help with this class of problem, but customized, application-level solutions can be tuned for specific application semantics and providing better feedback to end-users. The patterns in Part 5, "Concurrency Patterns," describe strategies for robust, concurrent data access with data integrity preservation being the prime motivating factor.
Transaction (379)— Executes concurrent units of work in an atomic, consistent, isolated, and durable manner. Nearly every database platform supports native transactions.
Optimistic Lock (395)— Maintains version information to prevent missing database updates. Optimistic locking uses application semantics to validate a working copy's version before updating the database.
Pessimistic Lock (405)— Attaches lock information to data to prevent missing database updates. Explicit pessimistic locking often offers better application diagnostics than analogous native transaction support.
Compensating Transaction (417)— Defines explicit compensating operations to roll back units of work that are not part of a native database transaction.
