[ Pobierz całość w formacie PDF ]

...
updateMessage(aMessageDTO)
...
get/setTitle
get/setBody
...
ThreadSummaryDTO
threadID
ForumServices
threadTitle
SessionBean
threadSummary
ViewThread
getMessageThreadSummaryDTOs
messageCount
Summaries
(forumID)
userFirstName
...
userLastName
messageID
getThreadID()
getXXX
...
Figure 6.10 Message Domain DTO.
From Requirements to Pattern-Driven Design 139
Here we show the two types of data transfer objects: domain and custom.
Message DTO is a domain DTO, because it maps directly to a Message domain
object. It is used both for retrieving a Message s data on the client and for send-
ing an updated version back to the server. ThreadSummary DTO on the other
hand, is a custom DTO that contains attributes from three different domain
objects: Thread, User, and Message. The ThreadSummary DTO is completely
UI-specific and is used to show a summary of threads, such as on TheServer-
Side.com s home page.
Data Transfer Object Factory
The Data Transfer Object pattern advocates encapsulating DTO creation and
consumption logic into a DTOFactory, which keeps entity beans clean of DTO
creation and consumption logic. Applied to our example, a DTOFactory
would extract DTO-related method from the ForumServices session bean,
either by implementing DTOFactory as another session bean, or as a plain Java
class that ForumServices delegates to, as shown in Figure 6.11.
DTOFactory as a DTOFactory as a
session bean plain class
ForumServices ForumServices
SessionBean SessionBean
postMessage
postMessage
addReply
addReply
signup
signup
...
updateMessage
getMessageDTO(messageID)
updateMessage(aMessageDTO)
...
ForumDTOFactory
delegates to
delegates to
Session Bean
getMessageThreadSummaryDTOs
(forumID)
ForumDTOFactory
getMessageDTO(messageID)
updateMessage(aMessageDTO)
getMessageThreadSummaryDTOs
...
(forumID)
getMessageDTO(messageID)
updateMessage(aMessageDTO)
...
Figure 6.11 DTOFactory Implementation options.
140 Chapter Six
Note that the main takeaway point of the Data Transfer Object pattern is that
DTOs should not be used between the services layer and the domain objects,
as was common in EJB 1.X, rather, domain objects should be kept clean of DTO
knowledge.
Data Transfer HashMaps:
A DTO Alternative
The examples shown above only show a limited number of DTOs to keep the
chapter more manageable, but often developers need to deal with an explo-
sion of DTOs. The Data Transfer HashMap pattern (Chapter 2) discusses how
a generic HashMap can be used to replace the entire DTO layer.
Data Transfer RowSets
As a Web-based site, almost every UI on TheServerSide is tabular in nature,
since HTML tables are the main way of organizing data on a Web page.
Furthermore, as a forum-messaging system, users of the site only have read-
only access. Thus, all use cases involving browsing the site (such as ViewThread,
ViewThreadSummaries) are read-only in nature and will be represented in
tabular form on TheServerSide. Thus, the ViewThreadSummaries use case
could be implemented as in Figure 6.12.
Using RowSets requires direct database access, thus, you should use them in
conjunction with the JDBC for Reading and the Data Access Command Bean
patterns.
Application Services Layer Persistence Layer
Layer
ForumServices
GetThreadSummaries
SessionBean
DACBean
requests RowSet uses
getThreadSummaryRowSet(forumID)
//input parameters
...
forumID
//return value container
RowSet forums;
setTitle(...)
setSubject(...)
setBody(...)
setUserID(...)
setForumID(...)
execute()
getRowSet()
Figure 6.12 Using RowSets for read-only use cases.
From Requirements to Pattern-Driven Design 141
Application Layer Patterns
Because this book is about EJB design patterns, it does not contain any patterns
that would change the actual architecture of the application layer (see Core
J2EE patterns [Alur, et al., 2001] for an excellent set of presentation and appli-
cation layer patterns), however, the book contains two important patterns that
provide best practices for how the application layer should interact with the
services layer:
EJBHomeFactory pattern. This pattern provides a clean, encapsulated and
high-performance mechanism for application layer clients to find EJB-
Homes. For example, rather than look up the home for ForumServices,
our use cases can simply call EJBHomeFactory.getFactory().
lookUpHome(ForumServicesHome.class). This also further simplifies
application layer logic by removing the burden of remembering JNDI
names (these are extracted into ejb-ref tags in web.xml).
Business Delegate. The Business Delegate pattern advocates creating a
thin plain Java class that hides the details and complexities of EJB from
the application logic. Using this pattern, application logic would inter-
face only with the business delegate, as shown in Figure 6.13. Note that
business delegates can be optimized by using the EJBHomeFactory.
Application Layer Services Layer
ForumServices
ForumServices
Delegate
delegates to
delegates to postMessage
Application uses
postMessage
addReply
Logic
addReply
updateMessage
updateMessage
createForum
createForum
...
...
uses
uses
EJBHomeFactory
Figure 6.13 Business delegate.
142 Chapter Six
The business delegate is most useful in large projects where there is a sepa-
ration between presentation/application layer programmers and EJB develop- [ Pobierz całość w formacie PDF ]