P. 1


|Views: 170|Likes:
Published by Arun Nair

More info:

Published by: Arun Nair on Jun 09, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Frank and some of his books
Frank Buschmann

Many business systems need to persist some or all of the data they
use. Distributed systems are no exception. There is a mismatch,
however, between the relational model, the dominant persistence
paradigm, and the object-oriented model, the favored paradigm for
distributed application development. This chapter presents five pat-
terns that help to bridge these two models, to support mapping
between object-oriented applications and relational databases.


Database Access

Many software systems use databases to store their persistent data.
In most of these systems the databases follow the relational model
for the following reasons, mainly due to economic factors:

• Existing legacy data and IT infrastructures. Databases are a com-
mon and long-standing feature of many IT organizations. As a
result, the cost of transferring data to a different database model,
or even to a different relational database, often outweigh the ben-
efits of such a change, even if another database is technically

• Customer support. Due to the maturity of relational databases
and the ecosystem that supports them, users typically receive
competent and timely customer support world-wide. This level
of service is not necessarily available for other database mod-

• Experience. Developers, administrators, and users of databases
are often most familiar with the relational database model, hav-
ing gained significant experience in designing and provisioning
applications that use relational databases, designing relational
database schemas, and tuning such databases. Achieving this
proficiency with other database models is expensive and time con-

Nevertheless, there are also two technical reasons that advocate the
use of relational databases:

• Performance. Over time, a great deal of effort has been invested
in optimizing relational databases. As a result, they provide good
performance for most applications that need to persist data.

• Data usage scenarios. The profile of application data and its use
fits best with the kind of collective and query-based relational model
supported by relational databases. From a bird’s-eye perspective,
most applications deal with data records that they use and mod-
ify, and collections of data records on which they perform typical
operations for collections, regardless of how data is represented in
the applications. This conceptual view of data is well-supported by
relational databases.

Although the relational model remains the dominant database
paradigm, the technologies used to design and implement appli-
cations have changed considerably over time. Two decades ago,

Database Access


procedural programming was common, whereas most new appli-
cations are now object-oriented. This trend, however, often causes
an impedance mismatch, since applications that use object fea-
tures such as inheritance, polymorphism, and navigational inter-
object relationships cannot map easily and efficiently to a relational
database schema.

There are dozens of patterns and pattern languages [BW95] [KC97]
[Kel99] [Fow03a] that describe how to combine relational and object-
oriented models effectively. Exploring them in detail, however, is
beyond the scope of our pattern language, which centers on building
distributed systems. However, because of the important role that
relational databases play in many distributed systems, we describe
the following key patterns that help to bridge the chasm [BW95]
between the object and the relational models:

The DATABASE ACCESS LAYER pattern (538) [KC97] separates an
object-oriented application design from a relational database by
introducing a mapping layer between the two.

The DATA MAPPER pattern (540) [Fow03a] acts as a mediator
that transfers data between an application and a database, to
decouple an object model from a relational database schema so
that the two can evolve independently.

The ROW DATA GATEWAY pattern (542) [Fow03a] introduces objects
that act as gateways to individual records in a database table,
but can be accessed using object-oriented programming mecha-

The TABLE DATA GATEWAY pattern (544) [Fow03a] introduces an
object that acts as a gateway to an entire database table, but can
be accessed using object-oriented programming mechanisms.

The ACTIVE RECORD architectural pattern (546) [Fow03a] speci-
fies an object that wraps a record data structure in an external
resource, such as a row in a database table, and provides addi-
tional domain logic for that object.

The DATABASE ACCESS LAYER pattern was published originally by Wolf-
gang Keller and Jens Coldewey [KC97]. The four other patterns are
found in Martin Fowler’s Patterns of Enterprise Application Architec-
ture [Fow03a]. Some patterns outlined above also appear in the J2EE
patterns literature [ACM01]: DATABASE ACCESS LAYER corresponds to


Database Access

All of these patterns connect to other, finer-grained and detailed pat-
terns for database access, which are also included in our pattern
language. For reasons of brevity, however, we refer only to their orig-
inal sources and do not describe them in detail. These other patterns
are documented in Patterns of Enterprise Application Architecture, but
most were also published earlier [BW95] [KC97] [Kel99].

DATABASE ACCESS LAYER can be considered the root pattern for deal-
ing with database access, whereas the other four patterns describe
approaches for the refinement of a database access layer.

• DATA MAPPER provides complete decoupling of an application’s data
model from the table format in which it is persisted. The pat-
tern is the most complex refinement option for a DATABASE ACCESS
LAYER access layer. It should therefore only be considered when
the mapping between the data model and the table formats is
not straightforward, for instance because the data model includes
cycles, or the information stored in data objects is spread across
multiple tables.

• ROW DATA GATEWAY and TABLE DATA GATEWAY also decouple the data
model of an application from database table formats. The two pat-
terns are most applicable if the application data model consists of
collections of homogeneous application data objects that can be
mapped directly onto corresponding database tables. If the appli-
cation’s programming platform offers support for record sets, such
as ADO.NET and JDBC 2.0, TABLE DATA GATEWAY is the best choice,
because record sets already provide an object-oriented encapsu-
lation for tabular data. Otherwise ROW DATA GATEWAY is the better
option: it provides explicit mapping between individual data objects
and data stored in a specific table row.

• ACTIVE RECORD relaxes the decoupling between the object-oriented
data model of the application and the table formats of the database.
The pattern simply wraps a specific table row within a database
table or view, and adds domain logic to that data. Due to this
tight coupling, ACTIVE RECORD should only be preferred if the data
to a single database table, and the database design—or even the
underlying database itself—does not change often during the appli-
cation’s lifetime.

Database Access


The following diagram illustrates how the five patterns for accessing
relational databases connect to our pattern language and to other
database access patterns and idioms.



data retrieval


mapping code

Domain Model


Data Transfer


Data Mapper

Access Layer

Identity Map

Lazy Load

Unit of Work

Record Set

Shared Repository


data access

Active Record

Table Data

Row Data






mapping code





Database Access

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->