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

EJBs like these that contain large amount of code cause several problems. The
lack of modularity makes them difficult to understand and maintain because it's
hard to find your way around long methods and large classes. They can be
extended to support new requirements only by adding more code, which makes
the problem worse. Complex EJB s are also very difficult to test because they lack
the subcomponents to test in isolation. But if this procedural design style has
these problems, why is it so common in J2EE application?
Why J2EE encourages developers to write procedural code
There are a couple of reasons why J2EE developers often write procedural-style
code rather than developing an object model. One reason is that the EJB specifi-
cation makes it seductively easy. Although the specification does not force you to
write this type of code, it lays down a path of least resistance that encourages state-
less, procedural code. When implementing new behavior, you don't have to worry
about identifying classes and assigning responsibilities as you would if you were
designing a real object model. Instead, you can write a new session bean method
or add code to an existing one.
The second reason why J2EE developers write procedural-style code is that it is
encouraged by the EJB architecture, literature, and culture, which place great
emphasis on EJB components. EJB 2 components are not suitable for implementing
an object model. Session beans and message-driven beans are monolithic, heavy-
weight classes that cannot be used to implement a fine-grained object model. Nor
can they represent business objects that are stored in a database. The best way to
use them in an application is to encapsulate an object model: the Session Façade and
Message Façade patterns.
EJB 2 entity beans, which are intended to represent business objects, have numer-
ous limitations that make it extremely difficult to use them to implement a persis-
tent object model. This is why I didn't use them in our earlier example. EJB 2 entity
beans support some kinds of relationships, but not inheritance. Entity beans do not
support recursive calls or “loopback” calls, which are common in an object model
and occur when object A calls object B, which calls object A. We'll discuss other lim-
itations of entity beans in a moment. Entity beans have so many limitations that it's
amazing that developers have used them successfully. This is a fundamental prob-
lem with the preferred J2EE architecture. Each framework creates a path of least
resistance for its use. It is possible to diverge from the path, but it goes against the
grain of the framework and takes a great deal of effort. The path of least resistance
in J2EE and EJB leads inexorably toward procedural code.