Implementing POJOs with EJB 3 - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 380

Table 10.1 Summary of the issues when using EJB 3 to persist the Food to Go domain model

Class Issue

PendingOrder.lineItems
Restaurant.menuItems

Either:
Add an index column to the element class.
Use a JBoss-specific annotation.

Restaurant.serviceArea Replace the Set<String> with a Set<ZipCode> .

Coupon class hierarchy Introduce an AbstractCouponImpl superclass.

Each modification is small, but lots of little changes like these accumulate and
introduce unnecessary complexity into the domain model. We must also decide
between using vendor extensions and making even more changes. Using vendor
extensions is appealing because it can reduce the amount of code that must be
written. The downside of using them is that the code is no longer portable between
EJB 3 implementations. This can sometimes be a difficult decision to make.
As well as defining the O/R mapping for a domain model, we must develop the
repositories, which define methods for creating, finding, and deleting persistent
objects. The next section shows you how.

10.2.2 Implementing repositories

In an EJB 3 application, the repositories use the EntityManager and Query inter-
faces to access the database. For example, listing 10.2 shows the EJB 3 implementa-
tion of the RestaurantRepository , which find restaurants using these interfaces. It
has a findRestaurant() method, which loads a single restaurant, and a find-
AvailableRestaurants() method, which finds all restaurants that serve the speci-
fied delivery address and time.

Listing 10.2 EJB3RestaurantRepository

public class EJB3RestaurantRepository implements
RestaurantRepository {

private EntityManager entityManager;

public EJB3RestaurantRepository(
EntityManager entityManager) {
bb this.entityManager = entityManager;

Saves EntityManager

}

public Restaurant findRestaurant(