Java Reference
In-Depth Information
2.2 Decision 1: organizing the business logic
These days a lot of attention is focused on the benefits and drawbacks of particu-
lar technologies. Although this is certainly very important, it is also essential to
think about how your business logic is structured. It is quite easy to write code
without giving much thought to how it is organized. For example, as I described
in the previous chapter it is too easy to add yet more code to a session bean
instead of carefully deciding which domain model class should be responsible for
the new functionality. Ideally, however, you should consciously organize your busi-
ness logic in the way that's the most appropriate for your application. After all,
I'm sure you've experienced the frustration of having to maintain someone else's
badly structured code.
The key decision you must make is whether to use an object-oriented approach
or a procedural approach. This isn't a decision about technologies, but your
choice of technologies can potentially constrain the organization of the business
logic. Using EJB 2 firmly pushes you toward a procedural design whereas POJO s
and lightweight frameworks enable you to choose the best approach for your par-
ticular application. Let's examine the options.
2.2.1
Using a procedural design
While I am a strong advocate of the object-oriented approach, there are some sit-
uations where it is overkill, such as when you are developing simple business logic.
Moreover, an object-oriented design is sometimes infeasible—for example, if you
do not have a persistence framework to map your object model to the database. In
such a situation, a better approach is to write procedural code and use what
Fowler calls the Transaction Script pattern [Fowler 2002]. Rather than doing any
object-oriented design, you simply write a method, which is called a transaction
script, to handle each request from the presentation tier.
An important characteristic of this approach is that the classes that implement
behavior are separate from those that store state. In an EJB 2 application, this typi-
cally means that your business logic will look similar to the design shown in
figure 2.2. This kind of design centralizes behavior in session beans or POJO s,
which implement the transaction scripts and manipulate “dumb” data objects that
have very little behavior. Because the behavior is concentrated in a few large
classes, the code can be difficult to understand and maintain.
The design is highly procedural, and relies on few of the capabilities of object-
oriented programming ( OOP ) languages. This is the type of design you would
create if you were writing the application in C or another non- OOP language.
 
 
 
 
 
 
Search WWH ::




Custom Search