Agile

作者在第8章对于使用Ejb给出了以下指南:

o Don't use entity beans if your EJB container supports only EJB 1.1
Entity beans as specified in EJB 1.1 were inadequate to meet most real-world requirements.

o Use CMP, not BMP
The greater control over the management of persistence offered by BMP is largely illusory. BMP entity beans are much harder to develop and maintain than CMP entity beans, and usually deliver worse performance.

o Use ejbHome() methods to perform any aggregate operations required on your data
ejbHome () methods, which can act on multiple entities, help to escape the row-level access imposed by the entity bean model, which can otherwise prevent efficient RDBMS usage.

o Use fine-grained entity beans
The "Composite Entity" pattern, often recommended for EJB 1.1 development, is obsolete in EJB 2.0. Implementing coarse-grained entities requires a lot of work, and is likely to deliver a poor
return on investment. If fine-grained, EJB 2.0 style, entity beans don't meet your requirements, it's likely that use of entity beans is inappropriate.

o Don't put business logic in entity beans
Entity beans should contain only persistence logic. When using EJB, business logic should normally go in session beans.

o Investigate your EJB container's locking and caching options for entity beans
Whether or not entity beans are a viable option depends on the sophistication of your EJB container's support for them. How you structure your entity bean deployment may have a big
effect on your application's performance.

分布式应用：

o Never allow remote clients to access entity beans directly; mediate entity bean access through
session beans, using the Session Facade pattern If remote clients access entities directly, the result is usually excessive network traffic and unacceptable performance. When any components outside the EJB tier access entity beans directly (even within the same JVM), they arguably become too closely coupled to the data access strategy in use.

o Give entity beans local interfaces, not remote interfaces
Accessing entity beans through remote interfaces has proven too slow to be practical. Remote clients should use a session facade.

o Create Value Objects in session beans, not entity beans
As we discussed in Chapter 7, value objects are often related to use cases, and hence to business logic. Business logic should be in session beans, not entity beans.

I prefer to manage persistence from session beans, using an abstraction layer of DAOs comprising a persistence facade. This approach decouples business logic code from the details of any particular persistence model.