manning Hibernate in Action phần 2 ppsx

Licensed to Jose Carlos Romero Figueroa <[email protected]>

20 CHAPTER 1

Understanding object/relational persistence

1.3.4 Considering EJB entity beans

In recent years, Enterprise JavaBeans (EJBs) have been a recommended way of

persisting data. If you’ve been working in the field of Java enterprise applications,

you’ve probably worked with EJBs and entity beans in particular. If you haven’t,

don’t worry—entity beans are rapidly declining in popularity. (Many of the devel￾oper concerns will be addressed in the new EJB 3.0 specification, however.)

Entity beans (in the current EJB 2.1 specification) are interesting because, in

contrast to the other solutions mentioned here, they were created entirely by

committee. The other solutions (the DAO pattern, serialization, and ORM) were

distilled from many years of experience; they represent approaches that have

stood the test of time. Unsurprisingly, perhaps, EJB 2.1 entity beans have been a

disaster in practice. Design flaws in the EJB specification prevent bean-managed

persistence (BMP) entity beans from performing efficiently. A marginally more

acceptable solution is container-managed persistence (CMP), at least since some glar￾ing deficiencies of the EJB 1.1 specification were rectified.

Nevertheless, CMP doesn’t represent a solution to the object/relational mis￾match. Here are six reasons why:

■ CMP beans are defined in one-to-one correspondence to the tables of the

relational model. Thus, they’re too coarse grained; they may not take full

advantage of Java’s rich typing. In a sense, CMP forces your domain model

into first normal form.

■ On the other hand, CMP beans are also too fine grained to realize the stated

goal of EJB: the definition of reusable software components. A reusable

component should be a very coarse-grained object, with an external inter￾face that is stable in the face of small changes to the database schema. (Yes,

we really did just claim that CMP entity beans are both too fine grained and

too coarse grained!)

■ Although EJBs may take advantage of implementation inheritance, entity

beans don’t support polymorphic associations and queries, one of the defin￾ing features of “true” ORM.

■ Entity beans, despite the stated goal of the EJB specification, aren’t portable

in practice. Capabilities of CMP engines vary widely between vendors, and

the mapping metadata is highly vendor-specific. Some projects have chosen

Hibernate for the simple reason that Hibernate applications are much

more portable between application servers.

Licensed to Jose Carlos Romero Figueroa <[email protected]>

Persistence layers and alternatives 21

■ Entity beans aren’t serializable. We find that we must define additional data

transfer objects (DTOs, also called value objects) when we need to transport

data to a remote client tier. The use of fine-grained method calls from the

client to a remote entity bean instance is not scalable; DTOs provide a way of

batching remote data access. The DTO pattern results in the growth of par￾allel class hierarchies, where each entity of the domain model is repre￾sented as both an entity bean and a DTO.

■ EJB is an intrusive model; it mandates an unnatural Java style and makes

reuse of code outside a specific container extremely difficult. This is a huge

barrier to unit test driven development (TDD). It even causes problems in

applications that require batch processing or other offline functions.

We won’t spend more time discussing the pros and cons of EJB 2.1 entity beans.

After looking at their persistence capabilities, we’ve come to the conclusion that

they aren’t suitable for a full object mapping. We’ll see what the new EJB 3.0 spec￾ification can improve. Let’s turn to another object persistence solution that

deserves some attention.

1.3.5 Object-oriented database systems

Since we work with objects in Java, it would be ideal if there were a way to store

those objects in a database without having to bend and twist the object model at

all. In the mid-1990s, new object-oriented database systems gained attention.

An object-oriented database management system (OODBMS) is more like an

extension to the application environment than an external data store. An OODBMS

usually features a multitiered implementation, with the backend data store, object

cache, and client application coupled tightly together and interacting via a propri￾etary network protocol.

Object-oriented database development begins with the top-down definition of

host language bindings that add persistence capabilities to the programming lan￾guage. Hence, object databases offer seamless integration into the object-oriented

application environment. This is different from the model used by today’s rela￾tional databases, where interaction with the database occurs via an intermediate

language (SQL).

Analogously to ANSI SQL, the standard query interface for relational databases,

there is a standard for object database products. The Object Data Management

Group (ODMG) specification defines an API, a query language, a metadata lan￾guage, and host language bindings for C++, SmallTalk, and Java. Most object­