Dashboard > Developers > ... > Persistence > Design pattern for persistence
  Developers Log In | Sign Up   View a printable version of the current page.  
  Design pattern for persistence
Added by Shinji KOBAYASHI, last edited by Shinji KOBAYASHI on 18-Jan-2008  (view change)
Labels: 
(None)

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

Site running on a free Atlassian Confluence Community License granted to The openEHR Foundation . Evaluate Confluence today.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.7 Build:#813 Aug 28, 2007) - Bug/feature request - Contact Administrators