java EJB 有什么用
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5579890/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What use are EJBs
提问by Raedwald
I'm currently learning Jave-EE, having plenty of C++ experience and having learned Java SE. I don't understand the purpose of Enterprise Java Beans; can someone clarify this for me. I'm not interested in legacyuses: this is in the context of EJB-3.1 and Java-EE 6.
我目前正在学习 Java-EE，拥有丰富的 C++ 经验并学习了 Java SE。我不明白 Enterprise Java Beans 的目的；有人可以为我澄清这一点。我对遗留用途不感兴趣：这是在 EJB-3.1 和 Java-EE 6 的上下文中。
It seems that some people use them to contain the business logic, for implementing the business layer of the conventional 3-layer architecture. That separates the domain logic from the domain objects, leading to an anemic domain model. But that goes against all my OOD instincts; I agree with Martin Fowler that it is an anti-pattern. Should I relax my objections to an anemic domain model? Or do EJBs have other uses?
似乎有人用它们来包含业务逻辑，用于实现传统三层架构的业务层。这将域逻辑与域对象分开，导致了一个贫乏的域模型。但这违背了我所有的 OOD 直觉；我同意 Martin Fowler 的观点，即这是一种反模式。我应该放松对贫血领域模型的反对吗？或者 EJB 有其他用途吗？
采纳答案by vickirk
Use of Java EE does not automatically imply a anemic domain model, just as you can write code in say java what does not make good use of best practices doesn't mean it's not possible in java. I believe Martin Fowler's point was J2EE (note the use of J2EE and not Java EE) pretty much enforced operation of logic and data. Using POJO based entities allows data and behaviour to modelled appropriately. The "business logic" in your EJBs typically orchestrates application of business logic but more often than not does not actually perform it, it is usually a very thin wrapper.
使用 Java EE 并不自动意味着贫血的域模型，就像你可以在说 java 中编写代码一样，不能很好地利用最佳实践并不意味着它在 java 中是不可能的。我相信 Martin Fowler 的观点是 J2EE（注意使用 J2EE 而不是 Java EE）几乎强制执行逻辑和数据操作。使用基于 POJO 的实体允许对数据和行为进行适当的建模。EJB 中的“业务逻辑”通常会编排业务逻辑的应用程序，但通常并不实际执行它，它通常是一个非常薄的包装器。
EJBs thus form your Service API, you need this whichever platform/framework you are using, you need to have something you can physically invoke, it is an entry point. Whether you are implementing using spring, web services etc... You need a service layer, there is nothing stopping this been implemented in Java EE. A rather contrived example
因此，EJB 形成了您的服务 API，无论您使用的是哪个平台/框架，您都需要它，您需要拥有可以物理调用的东西，它是一个入口点。无论您是使用 spring、Web 服务等实现...您都需要一个服务层，Java EE 中已经实现了这一点。一个相当人为的例子
@Stateless
public SomeServiceImpl implements SomeService
someServiceMethod() {
delegate.doSomething();
}
}
public SomeServiceDelegate implements SomeService
someServiceMethod() {
modelObject.doSomething();
}
}
I'm not going into the reasons to prefer EJBs over any other technology, just wanting to point out that using them doesn't mean your implementation can't use best practice.
我不打算讨论比任何其他技术更喜欢 EJB 的原因，只是想指出使用它们并不意味着您的实现不能使用最佳实践。
回答by Arjan Tijms
As indicated by several other answers, EJBs are perfect for implementing the service layer. They are a very modern, lightweight kind of bean in Java EE. Despite the name you cannot compare them with the draconian heavy weight EJB2 beasts that were in J2EE. Everyone agrees thosewere a disaster, but it's not 2002 anymore.
正如其他几个答案所示，EJB 非常适合实现服务层。它们是 Java EE 中一种非常现代的、轻量级的 bean。尽管名称如此，但您无法将它们与 J2EE 中严酷的重量级 EJB2 野兽相提并论。每个人都同意那是一场灾难，但现在已经不是 2002 年了。
Ever since EJB3 (2006), EJB beans have been a perfectly fine technology.
自 EJB3 (2006) 以来，EJB bean 一直是一项完美的技术。
They help a lothere by providing declarative transactions (every entry method automatically starts a transaction if one is not already in progress, although this can be changed if desired), pooling, security, locking, remoting and then some. See the following answers for some additional details:
它们通过提供声明性事务（如果一个事务尚未在进行中，每个入口方法都会自动启动一个事务，尽管如果需要可以更改）、池化、安全性、锁定、远程处理等等，在这里提供了很多帮助。有关一些其他详细信息，请参阅以下答案：
- Frameworks for Layering reusable Architectures
- In what situations are EJBs used ? Are they required in websites/ web-application development?
- EJB 3 or Hibernate 3
- @EJB injection vs lookup - performance issue
Transactions have been explained here, but to add to this: it's not something that's only needed for highly complex, highly secure systems. I would go as far to state it's a basicrequirement even when only dealing with databases. If I process a simple order, I want that the inventory and the order are both updated or both not at all. This is as basic as having PKs and FKs in your database to ensure integrity.
事务已在此处进行了解释，但要补充的是：它不仅仅是高度复杂、高度安全的系统才需要的东西。我什至会说这是一个基本要求，即使只处理数据库。如果我处理一个简单的订单，我希望库存和订单都更新或根本不更新。这与在数据库中包含 PK 和 FK 以确保完整性一样基本。
EJBs make it trivial to manage transactions. Without EJBs there's a lot of boilerplate code for starting, committing or rolling-back the tx.
EJB 使管理事务变得微不足道。如果没有 EJB，就会有很多样板代码用于启动、提交或回滚 tx。
One should also not underestimate the benefits of pooling and stubs that EJB provides. It means a bean can have a lot of EJBs injected, and you don't have to worry about them being instantiated each and every time such a bean is created. This would otherwise especially be troublesome when not all EJBs would be used every time.
人们也不应低估 EJB 提供的池化和存根的好处。这意味着一个 bean 可以注入很多 EJB，并且您不必担心每次创建这样的 bean 时它们都会被实例化。否则，当并非每次都使用所有 EJB 时，这将特别麻烦。
Because of pooling however, only very lightweight stubs are injected, which are more akin to a kind of URLs that point to an actual instance. These cost next to nothing in terms of memory or cpu overhead to inject.
然而，由于池化，只注入了非常轻量级的存根，这更类似于一种指向实际实例的 URL。就注入的内存或 CPU 开销而言，这些成本几乎为零。
EJBs also feature annotations to declare them being Singletons, arrange their locking behavior (write locks/read locks), declaring one should be initiated at startup, allow them to manage a so-called extended persistence context (a persistence context not scoped to a TX), etc.
EJB 还具有注释以声明它们是单例，安排它们的锁定行为（写锁/读锁），声明应该在启动时启动，允许它们管理所谓的扩展持久性上下文（持久性上下文不限于 TX ）， 等等。
These are all concerns you don't want in your slimentities. In many architectures, a User object for instance is a simple data entity that I want to send across layers. I don't want my User instance to have a sendMsg() method and have a JMS resource as a dependency, so that message sending can suddenly be done from some client. I'm not really sure why people think this is somehow 'natural' and 'OOP'.
这些都是您不希望在您的苗条实体中出现的问题。在许多体系结构中，例如 User 对象是一个简单的数据实体，我想跨层发送它。我不希望我的 User 实例有一个 sendMsg() 方法并且有一个 JMS 资源作为依赖，所以消息发送可以突然从某个客户端完成。我不太确定为什么人们认为这在某种程度上是“自然的”和“面向对象的”。
In the real world I also don't invoke a sendMsg operation on my friend Joe whenever I want to send him a postcard. Instead, I address a card and bring it to the postoffice or put it in a postbox.
在现实世界中，每当我想向他发送明信片时，我也不会对我的朋友 Joe 调用 sendMsg 操作。相反，我会写一张卡片并将其带到邮局或放入邮箱。
I also don't invoke a bake() operation on a cake. Instead, I put the cake in an oven, etc.
我也不会在蛋糕上调用 bake() 操作。相反，我把蛋糕放在烤箱里，等等。
回答by Heiko Rupp
You already cite the "implement business logic" use case.
您已经引用了“实现业务逻辑”用例。
EJBs - in EJB 3.x Session Beans, Message Driven Beans and in 3.1 the new Singleton Beans indeed allow you implement the biz logic. Session Beans often server as Facade where clients connect to. Those clients can be Servlets to serve content via e.g. HTTP or also "fat" clients that talk over other (more binary) protocols to the EJBs.
EJBs - 在 EJB 3.x Session Beans、Message Driven Beans 和 3.1 中新的 Singleton Beans 确实允许您实现 biz 逻辑。Session Beans 通常作为 Facade 服务于客户端连接的地方。这些客户端可以是通过 HTTP 等提供内容的 Servlet，也可以是通过其他（更多二进制）协议与 EJB 对话的“胖”客户端。
Message Driven Beans serve as endpoint of asynchronous communications and can themselves call methods on Session Beans as an example.
消息驱动的 Bean 作为异步通信的端点，作为一个例子，它们本身可以调用会话 Bean 上的方法。
All the EJBs have one thing in common, which makes them very attractive: they are managed by a container. So the container takes care of instantiation, pooling, Transactions, Security etc.
所有的 EJB 都有一个共同点，这使得它们非常有吸引力：它们由容器管理。所以容器负责实例化、池化、事务、安全等。
If you write in an EJB
如果您在 EJB 中编写
@Resource DataSource x;
The container makes sure that when your bean is ready to receive method calls, the variable 'x' contains a suitable data source.
容器确保当您的 bean 准备好接收方法调用时，变量“x”包含合适的数据源。
The pooling of Beans allows you to have many more clients connecting to a site than you could do without, as either the instances are shared (Stateless SB) or instances can be swapped out by the container to 2ndary storage if memory is tight and to re-activate them later.
Bean 的池化允许您有更多的客户端连接到一个站点，因为实例是共享的（无状态 SB），或者如果内存紧张，实例可以被容器换出到第二级存储并重新- 稍后激活它们。
In EJB 3, the old EntityBeans from EJB 1.x and 2.x are gone and replaced by JPA, which builds the domain data model of POJOs, which may either be annotated to provide the relational semantics or the semantics may be provided by external XML files.
在 EJB 3 中，EJB 1.x 和 2.x 中的旧 EntityBeans 消失了，取而代之的是 JPA，JPA 构建了 POJO 的域数据模型，它可以被注解以提供关系语义，也可以由外部提供语义XML 文件。
With JPA (which does not require EJBs at all), the EJBs often serve to implement the handling of those entities:
使用 JPA（根本不需要 EJB），EJB 通常用于实现对这些实体的处理：
@Stateless
public class MyBean {
@PersistenceContext EntityManager em;
public Foo getFoo(String name) {
Query q = em.createQuery("SELECT f FROM Foo f WHERE f.name = :name");
q.setParameter("name",name);
return q.getSingleValue();
}
}
回答by Michael Borgwardt
A couple of points:
几点：
- EJBs don't exist on their own; they live in an EJB container, which offers you some very useful services through them, such as declarative security, declarative transactions and relatively easy clustering.
- While it's true that anemic domain models are an antipattern: once your business logic becomes more complex, e.g. when multiple applications operate on the same model, separating most of the logic from the model becomes a matter of separation of concerns.
- EJB 不是独立存在的；它们存在于 EJB 容器中，通过它们为您提供一些非常有用的服务，例如声明式安全性、声明式事务和相对容易的集群。
- 虽然贫血领域模型确实是一种反模式：一旦您的业务逻辑变得更加复杂，例如，当多个应用程序在同一模型上运行时，将大部分逻辑与模型分离就变成了关注点分离的问题。
回答by Manuel Salvadores
Just a remark from personal experience ...
只是个人经验的评论...
I don't doubt of the benefits of EJBs, but having had worked with them, I see EJBs only fitting in cases where security and transactions are very important (i.e: financial applications). For 90% of cases you would be just fine without EJBs. Another thing ... scalability and EJBs are not good friends.
我不怀疑 EJB 的好处，但与他们合作过，我认为 EJB 只适用于安全和事务非常重要的情况（即：金融应用程序）。对于 90% 的情况，如果没有 EJB，您会很好。另一件事...可扩展性和 EJB 不是好朋友。
回答by Majed
Some guys tells in discussion like this the EJB become useful in EJB3 not before that, and that is not ture. right it became more powerful specially with the JPA, but EJB1.0 and EJB2.1 still did a lot. maybe they didn't use it in large applications so they say that.
有些人在这样的讨论中说 EJB 在 EJB3 中变得有用之前不是，那是不正确的。是的，特别是使用 JPA，它变得更加强大，但是 EJB1.0 和 EJB2.1 仍然做了很多。也许他们没有在大型应用程序中使用它，所以他们这么说。
for example POJO can't deal with a Transaction, so in EJB you can specify the transaction type for a specific method is it require a new transaction or it not from the transaction .
例如 POJO 不能处理事务，因此在 EJB 中，您可以为特定方法指定事务类型是需要新事务还是不需要新事务。
in my organization we have ERP build from scratch using and we use the EJB in the Business Logic, it was from 2000 and the EJB was Version 1.0 . and it's not only separate the business tier from the other thiers but it's also separate the system from each other, for Example: finance module is separate from HR module. and if they want to add a new module they can add it without restarting the system and it will integrate with the system in perfect way..
在我的组织中，我们从头开始使用 ERP 构建，我们在业务逻辑中使用 EJB，它是从 2000 年开始的，EJB 是 1.0 版。它不仅将业务层与其他层分开，而且还将系统彼此分开，例如：财务模块与人力资源模块分开。如果他们想添加一个新模块，他们可以在不重新启动系统的情况下添加它，它将以完美的方式与系统集成..
and remember this in the EJB: what you see in the code is nothing and what the EJB container is doing for you is every thing :) .
并在 EJB 中记住这一点：您在代码中看到的什么都不是，而 EJB 容器为您所做的就是一切:)。
