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

As a result, it has been difficult to do any true object-oriented development in
a J2EE application. Furthermore, this procedural design style is so ingrained in
the J2EE culture that it has even carried over into newer, non- EJB ways of develop-
ing J2EE applications. Some developers still view persistent objects simply as a
means to get data in and out of the database and write procedural business logic.
They develop what Fowler calls an “anemic domain model” [Fowler Anemic]. Just
as anemic blood lacks vitality, anemic object models only superficially model the
problem and consist of classes that implement little or no behavior

The pain of EJB development
Another problem with EJBs is that development and testing are painfully tedious
for the following reasons:

You must deal with annoyingly long edit-compile-debug cycles —Because EJB s are
server-side components, you must deploy them in the EJB container, which
is a time-consuming operation that interrupts your train of thought. Quite
often the time to redeploy a component crosses the 10-second threshold, at
which point you might be tempted to do something else, like surf the Web
or IM a friend. The impact on productivity is particularly frustrating when
doing test-driven development, where it is desirable to run the tests fre-
quently, every minute or two. Test-driven development and unit testing are
common best practices for Java development made difficult by the infra-
structure required when developing EJB s.

■

You face a lack of separation of concerns — EJB often forces you to solve several dif-
ficult problems simultaneously—business logic design, database schema
design, persistence mapping, etc.—rather than allowing you to work on one
problem at a time. Not only is this mentally overwhelming but it also adds to
the already long edit-compile-debug cycle. When you change a class, you
might have to update the database schema before you can test your changes.

■

You must write a lot of code to implement an EJB —You must write a home inter-
face, a component interface, the bean class, and a deployment descriptor,
which for an entity bean can be quite complex. In addition, you must write
a number of boilerplate bean class methods that are never actually called
but that are required by the interface the bean class implements. This code
isn't conceptually difficult, but it is busywork that you must endure.

■

You have to write data transfer objects —A data transfer object ( DTO ) is a dumb
data object that is returned by the EJB to its caller and contains the data the
presentation tier will display to the user. It is often just a copy of the data

■