什么时候用EJB ,什么时候不用EJB?
来源:互联网 发布:淘宝价格打折有权重吗 编辑:程序博客网 时间:2024/04/28 17:48
什么时候用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.
- 什么时候用EJB ,什么时候不用EJB?
- 什么时候在EJB系统中使用XML
- C++什么时候用new,什么时候不用new
- 关于EJB,为什么用EJB?为什么不用EJB?
- c++什么时候该用引用,什么时候可以不用
- koa里面什么时候用 next, 什么时候不用next
- 在引入资源文件时,classpath 什么时候用,什么时候不用
- 什么时候用C而不用C++?
- 什么时候用C而不用C++
- 什么时候不用shell
- 什么时候不用shell
- angularjs里 什么时候加{{}} 什么时候不用?
- 什么时候
- 什么时候
- 何时不用EJB技术
- hibernate中lazy什么时候不用
- hibernate中lazy什么时候不用
- EJB
- 选择颜色的特效网页
- 对于linux分区的一些建议
- 数据库设计说明书(GB8567——88)
- javax.servlet.ServletRequestEvent翻译
- Java打印程序设计
- 什么时候用EJB ,什么时候不用EJB?
- TC2.0库函数查询 V1.0 破解全过程(原创)
- JAVA上加密算法的实现用例
- 不吐不快的专访感受
- 笔记本评测工具
- 电脑族养生应从养肝开始(转)
- javax.servlet.ServletRequestListener翻译
- Java用于嵌入式系统的十大优点和五个局限
- 生活被人偷窥了