什么时候用EJB ，什么时候不用EJB？

参考 Enterprise JavaBeans 4

这篇文章 讲述了何时使用EJB，何时不用EJB，以及用哪些可以替代EJB！

1 When to Use EJBs
Here's a list of situations where EJBs are strong; we haven't distinguished between

different types of EJBs.

Single and multisystem business transactions

The ability to maintain transactional integrity for complex business entities is one of

an EJB's key strengths. EJBs aren't alone in providing straightforward transactional

control over a single data repository. However, EJBs shine where multiple resources

(relational databases, messaging systems, etc.) are involved because they allow

transactions to spread across as many different resources as you like, so long as the

resources support distributed transactions.

Distributed functionality

Business services often live on a remote server. For example, a business enterprise will

have many different systems, ranging in degrees of inflexibility and entrenchment. One of

these systems may need to access another; EJBs, which are inherently distributed, are

often the simplest way to distribute remote services. EJB also allows you to provide

business services to remote clients more easily than some alternatives. Remote access

through components is easier to maintain than direct database access, because the

component code can shield the client from database schema changes.

Portable components (not classes)

Until recently, if you wanted to share your business services with another application

developer, you were forced to share classes or at least packages. Java did not allow for

the easy creation of enterprise components, reusable software building blocks that can be

assembled with other components to form an application. EJBs allow you to package your

business logic into a tidy, distributable unit that can be shared in a loosely coupled

fashion. The user of your component need only tweak a descriptor file for her

environment.

Applications relying on asynchronous messaging

EJBs (specifically MDBs) provide a strong technology for handling asynchronous

communication such as JMS-based messaging or web services.

Security roles

If your application's business operations can be mapped to specific business roles in

your enterprise, then EJBs may be a good choice. So much is made of the transaction

management capability of EJBs that their deployment-descriptor-based security management

features are overlooked. This capability is very powerful; if your application's users

fit into distinct roles and the rules for those roles dictate which users can write what

data, EJBs are a good choice.

2 When Not to Use EJBs
There are several situations in building a software application—even an "enterprise"

software application—in which using EJBs may actually be a barrier to meeting your

business goals. The following list represents places where you might not want to use

EJBs:

Read-mostly applications

If your application requires only (or even mostly) database reads (as opposed to writes),

then the added complexity and performance overhead of EJBs may be unwarranted. If your

application is only reading and presenting data, you should go with straight JDBC (see

below) or another persistence mechanism. That said, if your application's writes

(database update and inserts) require transactional support (especially if those

transactions go over multiple systems), then EJBs may be the way to go—at least for the

write portion of the application.

Applications requiring thread control

If your application design requires extensive use of threads, then the EJB spec actually

prevents you from using EJBs (although some EJB container vendors may provide nonportable

ways around this restriction). Container systems manage resources, transactions,

security, and other qualities of service using threads; threads you create are outside of

the container's control and can potentially cause system failures. Also, EJB containers

may distribute EJBs across multiple JVMs, preventing the synchronization of threads.

Performance

Because EJBs do so much more than plain Java classes, they are slower than plain Java

classes. The EJB container has to do a lot: maintain transactional integrity, manage bean

instances and the bean pools, enforce security roles, manage resources and resource

pools, coordinate distributed operations, synchronize shared services (if the vendor

offers clustering capabilities), and so on. The security and transactional management

operations can have a significant impact on the performance of method calls (on both

local and remote interfaces). If you require real-time or near-real-time performance

characteristics, EJB may not be your best choice.

3 Alternatives to EJB
There are several alternatives to EJB; some of them are growing in popularity and

maturity. EJBs still rank as the de facto standard for enterprise transactional needs,

but some of the alternatives, like JDO, are also available.

3.1 JDBC

3.2 Java Data Objects

3.3 Others

Castor JDO (http://www.exolab.org)

Hibernate (http://www.hibernate.org)

Prevayler (http://www.prevayler.org)

As you can see, there are several alternatives to EJB. If your application doesn't need

the complexity or some of the features of EJB, take a look around. Data persistence with

Java has been around for some time and there is a wide assortment of approaches.