Building a robust persistence layer

The Design of aRobust Persistence LayerFor Relational Databases

Scott W. Ambler

Senior Consultant, Ambysoft Inc.www.ambysoft.com/scottAmbler.html

http://www.ambysoft.com/downloads/persistenceLayer.pdf This Version: June 21, 2005

2

Table Of Contents

1.

GOOD THINGS TO KNOW ABOUT THIS PAPER........................................................................1

2.

KINDS OF PERSISTENCE LAYERS.................................................................................................1

3.

THE CLASS-TYPE ARCHITECTURE..............................................................................................3

4.

REQUIREMENTS FOR A PERSISTENCE LAYER........................................................................5

5.

THE DESIGN OF A PERSISTENCE LAYER...................................................................................8

5.1

O

VERVIEW OF THE

D

ESIGN

...............................................................................................................8

5.1.1

The PersistentObject Class......................................................................................................9

5.1.2

The PersistentCriteria Class Hierarchy.................................................................................10

5.1.3

The Cursor Class...................................................................................................................12

5.1.4

The PersistentTransaction Class...........................................................................................13

5.1.5

The PersistenceBroker Class.................................................................................................14

5.1.6

The PersistenceMechanism Class Hierarchy.........................................................................15

5.1.7

The Map Classes....................................................................................................................16

5.1.8

The SqlStatement Class Hierarchy........................................................................................18

6.

IMPLEMENTING THE PERSISTENCE LAYER..........................................................................19

6.1

B

UY

V

ERSUS

B

UILD

.......................................................................................................................19

6.2

C

ONCURRENCY

,

O

BJECTS

,

AND

R

OW

L

OCKING

..............................................................................19

6.3

D

EVELOPMENT

L

ANGUAGE

I

SSUES

.................................................................................................20

6.4

A

D

EVELOPMENT

S

CHEDULE

..........................................................................................................21

7.

DOING A DATA LOAD.....................................................................................................................21

7.1

T

RADITIONAL

D

ATA

L

OADING

A

PPROACHES

..................................................................................21

7.2

A

RCHITECTED

D

ATA

L

OADING

.......................................................................................................22

8.

SUPPORTING THE PERSISTENCE LAYER.................................................................................23

9.

SUMMARY..........................................................................................................................................25

10.

ABOUT THE AUTHOR.................................................................................................................25

11.

REFERENCES AND RECOMMENDED READING.................................................................26

1In this white paper I present an overview of the design of a robust persistence layer for object-orientedapplications. I have implemented all or portions of this design in several languages, in other words, thisdesign has been proven in practice.

1. Good Things to Know About This Paper

1.

I assume that you have read my white paper entitled

Object/Relational Mapping 101

atwww.agiledata.org/essays/mappingObjects.html.2.

Throughout this paper I will use the Unified Modeling Language (UML) version to represent mymodels.3.

Accessor methods, also known as getters and setters, are assumed for all attributes.4.

All attributes are private.5.

When I refer to an instance of class X, the implication is that I’m really referring to instances of class Xor any of its subclasses. This concept is called the Liskov Substitution Principle.6.

I do not present code for the persistence layer (and I will not distribute it), nor do I go into language-specific issues in the design. I will however discuss implementation issues at the end of the paper.

2. Kinds of Persistence Layers

I would like to begin with a discussion of the common approaches to persistence thatare currently in practice today. Figure 1 presents the most common, and leastpalatable, approach to persistence in which Structured Query Language (SQL) codeis embedded in the source code of your classes. The advantage of this approach isthat it allows you to write code very quickly and is a viable approach for smallapplications and/or prototypes. The disadvantage is that it directly couples yourbusiness classes with the schema of your relational database, implying that a simplechange such as renaming a column or porting to another database results in a rework of your source code.

Hard-coded SQLin your businessclasses results incode that isdifficult tomaintain andextend.

Figure 1. Hard-coding SQL in your domain/business classes.

Figure 2 presents a slightly better approach in which the SQL statements for your businessclasses are encapsulated in one or more “data classes.” Once again, this approach issuitable for prototypes and small systems of less than 40 to 50 business classes but it stillresults in a recompilation (of your data classes) when simple changes to the database aremade. Examples of this approach include developing stored procedures in the database torepresent objects (replacing the data classes of Figure 2) and Enterprise JavaBean (EJB)’sentity bean strategy. The best thing that can be said about this approach is that you have atleast encapsulated the source code that handles the hard-coded interactions in one place,the data classes.

HardcodingSQL inseparate dataclasses orstoredprocedures isonly slightlybetter.

Category:	Uncategorized.
Rating:
Upload Date:	03/28/2008
Copyright:	Attribution Non-commercial
Tags:	Technology Technology (fewer)

Documents

People