P. 1
Wiley.pattern.oriented.software.architecture.volume.4.May.2007

Wiley.pattern.oriented.software.architecture.volume.4.May.2007

|Views: 170|Likes:
Published by Arun Nair

More info:

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

Availability:

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

11/24/2015

pdf

text

original

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.

534

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
superior.

• 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-
els.

• 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-
suming.

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

535

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-
nisms.

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
DOMAIN STORE, and TABLE DATA GATEWAY to DATA ACCESS OBJECT.

536

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
object’sdomainlogicissimple,itsdatarepresentationmapsdirectly
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

537

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
finding

cycle
handling

on-demand
data retrieval

update
coordination

mapping code
generation

Domain Model

Registry

Data Transfer
Object

Metadata
Modeling

Data Mapper

Database
Access Layer

Identity Map

Lazy Load

Unit of Work

Record Set

Shared Repository

Blackboard

data access

Active Record

Table Data
Gateway

Row Data
Gateway

internal
design

internal
design

internal
design

internal
design

result
encapsulation

mapping code
generation

Observer

Object
Manager

connection
management

538

Database Access

You're Reading a Free Preview

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