[ Pobierz całość w formacie PDF ]

actually added the message to the forum (and thus these use cases would now
become synchronous in nature).
In the services layer, these use cases would be implemented as two methods
on a stateless session bean: postMessage and addReply. For example, the business
logic of the postMessage use case would be encapsulated on a session bean
method, and consist of creating a Message and passing it to the postMessage
method on a Forum. Thus, domain logic is maintained on the domain model,
but the workflow required to fulfill the use case (creating the Message and
then passing it to the Forum), is on the session bean, as in Figure 6.7.
Application Message Forum
ForumServices
Forum
Layer LocalHome LocalHome
create(...)
findByPrimar
yKey(carPK)
postMessage(...)
findByPrimar
findByPrimaryKey(forumID)
yKey(forumID)
Network
postMessage(aMessage)
postMessage(aMessage)
Figure 6.7 Post Message use case on a session façade.
136 Chapter Six
When we use the Session Façade pattern to design the architecture of a ser-
vices layer, use cases and processes of a similar nature should be grouped
together as methods of the same session bean (see the Session Façade pattern
for more info). Thus, services layer of our application could potentially be split
into two session beans, one that contains all the use cases that are forum-mes-
sage board related, and one that is related to users and use cases surrounding
users, as shown in Figure 6.8.
The only other way to implement the architecture of the services layer is by
using the EJB Command Pattern, which replaces the session façade.
EJB Command Pattern
The EJB Command pattern (Chapter 1) is an alternate way to implement a use
case s services layer business logic. The easiest way to think of the Command
pattern is as a lighter-weight session façade, that also has the benefit of decou-
pling the client from the details of EJB (similar to the Business Delegate pat-
tern, covered later in this chapter).
Using the Command pattern, the business logic from each use case is encap-
sulated into small, lightweight command beans, resulting in a services layer
consisting of many fine-grained commands (one per use case) that looks like
Figure 6.9.
ForumServices
postMessage
addReply
updateMessage
createForum
...
UserServices
createUser
editUser
editUserPreferences
getUserProfile
...
Figure 6.8 Session Façade Services Layer for TheServerSide.
From Requirements to Pattern-Driven Design 137
PostMessage AddReply CreateUser
Command Command Command
//setter methods //setter methods //setter methods
... ... ...
execute() execute() execute()
//getter methods //getter methods //getter methods
... ... ...
... ... ...
Figure 6.9 Services Layer with Command pattern.
Other Services Layer Patterns
The Session Façade, Message Façade and Command patterns illustrated how
our use case s business logic could be constructed on the services layer. How-
ever, certain use cases require that the business logic within the façade and
command patterns be designed differently, to address performance and main-
tainability concerns:
Performance. As mentioned in the persistence layer pattern, for use cases
that are read-only in nature, the JDBC for Reading pattern (Chapter 3)
can help improve performance by circumventing the entity bean domain
layer in favor of direct database access. Using this pattern, the
ViewThread and ViewThreadSummaries use cases would have their ser-
vices layer business logic skip the Forum and Thread domain objects, in
favor of interacting directly with the persistence layer (using the Data
Access Command Bean pattern).
Maintainability. The Data Transfer Object pattern suggests particular best
practices for how the services layer should construct data transfer objects
and return them to the client. The implementation of this pattern lives in
the services layer, but we will cover it in the next section, after introduc-
ing the Data Transfer Object pattern in relation to our sample case.
Inter-Tier Data Transfer Patterns
Each use case in our application involves communication between the appli-
cation layer and the services layer, and needs a mechanism to transfer data
from one layer to the other.
138 Chapter Six
The Data Transfer Object pattern in combination with the Session Façade
pattern is the most commonly used architecture among EJB developers. The
DTO pattern advocates creating a plain, serializable Java class that acts as an
envelope, carrying large amounts of data (in one network call) from server to
client and from client to server. As an alternative, HashMaps can also be used
in place of DTOs (explained below).
RowSets also provide an excellent alternative to DTOs, when transferring
read-only data intended for tabular display (explained below).
Data Transfer Objects
Applied to TheServerSide, a DTO would need to be created for almost every
use case, since all of them (except for the login use case) require some transfer
of data between application and services layer. Using the DTO pattern, a layer
of DTOs would be created, as shown in Figure 6.10. Note the method names on
the ForumServices class.
Use cases
Related Services Layer
DTOs (interlayer)
Methods
MessageDTO
ForumServices
title
SessionBean
body
EditMessage [ Pobierz całość w formacie PDF ]

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

domowewypieki.keep.pl