Developing with POJOs: faster and easier - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 8

when using EJB s doesn't allow developers to take advantage of many of the best
practices used for “normal” Java development.
The shortcomings of procedural design
There are two main ways to organize business logic: procedural or object-
oriented. The procedural approach organizes the code around functions that
manipulate separate simple data objects. In procedural architectures, data struc-
tures are populated, passed as parameters to functions, and returned to the caller.
The relationship between the data and the operations is very loosely defined, and
wholly maintained by the developer. Prior to object-oriented languages, this style
of programming dominated software development, and was featured in C, Pascal,
and other languages.
By contrast, the object-oriented approach organizes code around objects that
have state and behavior and that collaborate with other objects. The data struc-
tures and operations are defined in one language construct, co-locating the data
and the operations on the data. The relationship (and state) between the data
and the operations is maintained by the language. An object-oriented design is
easier to understand, maintain, extend, and test than a procedural design.
Despite the benefits of an object-oriented design, most J2EE applications,
including the one shown in figure 1.1, are written in a procedural style. In our
example, all of the business logic is concentrated in the TransferService EJB ,
which consists of the transfer() method and possibly one or more helper meth-
ods. None of the objects manipulated by the TransferService EJB implement any
business logic. These objects exist to provide plumbing and services to the
TransferService EJB . The DAO s are wrappers around JDBC , and the remaining
objects (including the entity beans) are simple data objects. Even though this
business logic is written in Java, which is an object-oriented language, this design
fits the definition of procedural code exactly.
The procedural design style isn't a problem if the business logic is simple, but
business logic has a habit of growing in complexity. As the requirements change
and the business logic has to implement new features, the amount of code in the
EJB steadily increases. For example, in order to add a new kind of overdraft policy
you would have to add yet more code to the TransferService EJB to implement
that new policy. Even if each enhancement only adds a few lines of code, EJB s that
started out quite simple over time can grow into large complex beasts, such as the
ones that I encountered on one early J2EE project that were each many hundred
of lines of code.