Design pattern for persistence

There are several petterns for persistent object, which are distinguished  to major two categories by using object / relational database mapper (O/R mapper) or not. All the petterns are designed to abstract database transaction and to standardise the method without coding around difference  behavior of each database. Some programming languages have standard API for persistence, eg. Java Persistence Interface, Perl DBI.

I introduce some of the petterns for discussion of the openEHR persistence API. This section will be change frequently because I am now studying about these pattern for implementation on Ruby. Please point out and comment me, if you find my mistake.

PoEAA proposes that enterprise application architecture has three layers, such as presentation layer, domain layer and data source layer. I think persistence API is friged between domain layer and data source layer.

1. Domain Logic pettern

This model has layers like openEHR, such as Service layer, Transaction script, Domain model and Table module. This model is well abstracted enough to standardise database access method, if it is OODB, RDBMS, XMLDB or others. Otherwise the implementation will be difficult because this model has some complexity about relationship of classes.

2. Data source architectural pattern

This pattern  has simple gateway for DBMS. But this method is mainly target to RDBMS.

Refferences

1.  Martin Fowler, Patterns of Enterprise Application Architecture, 2002