[ Pobierz całość w formacie PDF ]
can be very quick to hack together an application by not putting in the
up-front time to build a nice domain model. For example, the forums
subsystem of TheServerSide is extremely simple there are only four
domain objects. Thus, the initial launch of TheServerSide (which only
had a forums subsystem at the time), could have arrived a lot quicker if
time wasn t spent writing a nice BMP-entity-bean-based domain model.
Luckily, this course of action was not taken. TheServerSide ended up
growing and changing with the times, and the OO domain model back
end helped ease the maintenance burden along the way.
Able to circumvent the domain model for performance reasons.
Developers may want to at least circumvent a domain model and write
persistence logic themselves when implementing a use case that is read-
only in nature, such as ViewThreadSumaries or ViewThread. For the
reasons expressed in the JDBC for Reading pattern (Chapter 3), it can be
a lot faster to circumvent the domain model and go straight to the
database for these types of operations.
From Requirements to Pattern-Driven Design 131
Persistence Layer Patterns without a
Domain Layer
When designing a system without a domain layer, then the Data Access
Command Bean pattern (Chapter 3) provides a best practice for architecting a
persistence layer. Using this pattern, the persistence layer implementation of
the PostMessage and ViewThreadSummaries use cases would be implemented
using data access command beans, as shown in Figure 6.5.
In a similar fashion, all of the use cases in our system would eventually map
down to a DACB that handles its persistence. Data access command beans
provide a standard and efficient way to completely encapsulate persistence
logic behind a set of command beans. In effect, they become the persistence
layer and the domain layer in an application.
Persistence Layer Patterns with a
Domain Model
If you have made the good decision to model your business problem with an
object-oriented domain model, then the question of what patterns apply in the
persistence layer depends on what technology you are using to implement
your domain model. The domain model implementation technology choices
can be divided into two types: those that generate the persistence code for you
and those that do not, as explained below:
PostMessage ViewThreadsSummaries
DACBean DACBean
//input parameters //input parameters
title forumID
subject
body //return value container
userID RowSet forums;
forumID
setTitle(...)
setSubject(...)
//return values
setBody(...)
messageID
setUserID(...)
setTitle(...)
setForumID(...)
setSubject(...)
setBody(...)
execute()
setUserID(...)
setForumID(...)
getThreadID()
getThreadTitle()
execute()
getThreadSummary()
getUserFirstName()
getMessageID()
getUserLastName()
getMessageCount()
getMessageID()
next()
Figure 6.5 Persistence layer with data access command beans.
132 Chapter Six
Use generated Persistence Logic. CMP entity beans, JDO, and the use
of object/relational mapping tools provide you with a technology for
implementing your domain model without having to write any persis-
tence logic. They allow you to write your domain objects and have a tool
automatically persist your domain objects to a data store. Since the per-
sistence layer is generated, there is no place for developers to apply any
patterns.
Do it yourself. Bean-managed persistent entity beans are an example of a
domain model technology that requires the developer to write all the
persistence logic. Despite the fact that BMP beans allow (and encourage)
you to write your persistence code directly into the domain object itself
(in the ejbLoad/Store/Create/Find/Delete), developers should still
consider creating a separate persistence layer, and here there are design
patterns to help you out.
A persistence layer can be created beneath a BMP entity bean domain layer
using the Data Access Command Bean pattern (Chapter 3), much in the same
way that it was applied in Figure 6.5. This will allow you to keep your BMP
entity beans free of any persistence logic, localizing the logic to its own well-
encapsulated layer of classes. Another useful pattern for this is the Data Access
Object pattern (Alur, et al., 2001).
Patterns for the Domain Layer
At the domain layer, numerous patterns apply, depending on the context and
problem being solved. In this section, we will evaluate the requirements of
TheServerSide and choose implementations depending on factors affecting
concurrency, portability, maintainability, the use of tools, and the need to gen-
erate primary keys.
Concurrency. Among the use cases outlined in Figure 6.1, the EditMessage
use case opens the potential for corruption of the underlying database
unless special precautions are taken. Figure 6.1 shows that only site
administrators can edit a message. But what happens when two differ-
ent administrators attempt to edit the same message? As explained in
the Version Number pattern (Chapter 3), there is a potential for the two
administrators to overwrite each other s changes. The solution is to use
the Version Number pattern, which would cause us to add optimistic
concurrency checks to the domain objects that have use cases that could
[ Pobierz całość w formacie PDF ]