Entities and entity beans
EJB 3 entities and EJB 2.x entity beans are different beasts from the other kinds of Enterprise JavaBeans, session beans, and message-driven beans. Entities represent data and operations related to finding entities by various criteria, modifying the data represented by a given entity bean instance, and creating and deleting data—in other words, persistent objects.
The majority of entity beans written by corporate developers have traditionally had no functionality beyond what's generated by the EJB container for implementing the persistence to a backing database—with the exception of entities that use bean-managed persistence (BMP), implementing their own persistence logic (typically using the JDBC API). Figure 13.7 illustrates this common division of responsibility, which hasn't promoted good object-oriented design in many enterprise systems.
|
EJB container | ||||
|
Business objects |
Persistent objects | |||
|
^^^Entity bearT^^) | ||||
|
(^^Entity bearT^^) | ||||
|
^^^ession beâf^^^ | ||||
Figure 13.7 The only role of entity beans in a typical EJB-based architecture is persistence.
Figure 13.7 The only role of entity beans in a typical EJB-based architecture is persistence.
This has been our playing field for the past several years when it comes to the EJB 2.x specification and persistent objects. Along with the EJB 3 specification, we got a new Persistence API to supersede entity beans. The Persistence API simplifies the way persistent entities are developed, also making quantum leaps in terms of testability. The downside of the improvement is, unfortunately, that all this time "easily testable entity beans" has been an oxymoron.
For the remainder of this chapter, we'll look into how we can test and test-drive entity beans. I'll start by discussing the old EJB 2.x API and what our options are regarding unit testing and test-driven development.5 Then, we'll look more closely into how the new Persistence API enables our TDD process for developing entity beans.
Post a comment