Java Reference
In-Depth Information
Legend:
Behavior
State
Figure 2.3
The structure of a domain model:
small classes that have state and
behavior
Another name for an object model is a domain model, and Fowler calls the
object-oriented approach to developing business logic the Domain Model pattern
[Fowler 2002]. In chapter 3 I describe one way to develop a domain model and in
chapters 4-6 you will learn about how to persist a domain model with Hibernate
and JDO .
2.2.3
Table Module pattern
I have always developed applications using the Domain Model and Transaction
Script patterns. But I once heard rumors of an enterprise Java application that
used a third approach, which is what Martin Fowler calls the Table Module pattern.
This pattern is more structured than the Transaction Script pattern, because for
each database table it defines a table module class that implements the code that
operates on that table. But like the Transaction Script pattern it separates state
and behavior into separate classes because an instance of a table module class rep-
resents the entire database rather individual rows. As a result, maintainability is a
problem. Consequently, there is very little benefit to using the Table Module pat-
tern, and so I'm not going to look at it in anymore detail in this topic.
2.3 Decision 2: encapsulating the business logic
In the previous section, I covered how to organize the business logic. You must also
decide what kind of interface the business logic should have. The business logic's
interface consists of those types and methods that are callable by the presentation
tier. An important consideration when designing the interface is how much of the
business logic's implementation should be encapsulated and therefore not visible
to the presentation tier. Encapsulation improves maintainability because by hiding
 
 
 
 
 
 
Search WWH ::




Custom Search