豆子，豆子，还有更多的豆子......什么是什么？
我最近接到一个项目，其中涉及编写一个 Web 应用程序。我以前从未接触过 Java EE。网络上的许多资源都已过时，我很难弄清楚各种标准和 Java 技术之间当前的差异。
最初我认为由于依赖注入、JPA、会话管理和 Web 服务，我确实需要 EJB 3.1。我开始尝试 Glassfish，但被告知我们必须在 Tomcat 中编写这个东西。因此，我一直在努力弄清楚我需要什么，以及将什么以及如何放入 Tomcat 中才能实现这一目标。我开始怀疑我是否真的需要 EJB。
我想，我想将 JFS 用于 MVC 架构。在了解这一点的过程中，我遇到了 ManagedBeans 和 CDI，根据一些说法，前者已经过时，并且似乎还提供了我想要启用单元测试的所有依赖项注入内容。我还开始意识到，我可以以 Hibernate 或其他一些形式在 EJB 之外获取 JPA。另外，我不知道我是否需要的网络服务似乎以另一种标准的形式出现，我现在想不出这个标准，而且它也可以独立安装。
我这里的主要问题是会话管理和状态。在我看来，EJB 剩下要做的就是提供@Stateless/@Stateful 和@Local/@Remote。然而，据我了解，其中一些已经以会话管理的形式存在于 servlet 容器中......但我不知道我需要考虑多少或哪些主要差异才能决定如果我真的需要这些东西的话。
所以我的问题是，为了决定 EJB 是否值得研究，或者我是否有足够的其他库和技术形式，我需要了解哪些基本的、本质的区别？我已经遍及谷歌和新闻组，但无法在任何地方找到此信息。
刚刚又想到了一点。据我了解，@Stateful bean注释为我提供了线程安全的状态保存。我可能不会直接使用线程，但我知道 Java 在幕后经常这样做，并且怀疑 EE 尤其如此。当我需要保持状态时，如果这已经提供了线程，我不想处理线程。
I've recently been given a project to work on that involves writing a web application. I've never done Java EE before. A lot of resources on the web are dated and I'm having trouble figuring out what the current differences are between the various standards and Java technologies.
Originally I thought I really needed EJB 3.1 due to dependency injection, JPA, session management, and web services. I started experimenting with Glassfish but was told that we had to write the thing in Tomcat. So I've been trying to figure out what I need as well as what and how to put into Tomcat to get there. I've begun to question whether I even need EJB at all.
I want to use JFS, I think, for the MVC architecture. In learning about that I've run into both ManagedBeans and CDI, which according to some renders the former obsolete and also seems to provide all the dependency injection stuff I want to enable unit testing. I've also come to realize that I can get JPA outside of EJB in the form of Hibernate and maybe a few others. Additionally it seems that web services, which I don't know that I need anyway, come in the form of another standard I can't think of the name right now and this also can be installed independently.
My major issue here is session management and state. It seems to me that all which remains for EJB to do is provide @Stateless/@Stateful and @Local/@Remote. However, as I understand it, some of this is already exists in the form of session management in the servlet container...but I don't know how much or what the major differences are that I need to account for in order to decide if I need these things at all.
So my question is, what are the basic, essential differences that I need to know in order to decide if EJB is worth looking at or if I have enough in the form of other libraries and technologies? I've been all over google and Usenet and have not been able to find this information anywhere.
Just thought of another bit. As I understand it, the @Stateful bean annotation provides me thread-safe state saving. I'm probably not going to directly use threads, but I know Java does so behind the scenes a lot and suspect EE especially so. When I need to keep state I don't want to be dealing with threads if this already provides it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
ManagedBean
Java EE 6 具有三种不同的方式来定义
bean，这些bean在无论如何：@javax.faces.bean.ManagedBeanJSF 2.0 引入了此注释，在 faces-config.xml 中声明托管 bean。该注释用于从表达式语言访问 bean。
@javax.inject.Named在 EE 6 容器 CDI 中，此注释是内置限定符类型，用于为 bean 提供名称，使其可通过 EL 进行访问。
@javax.annotation.ManagedBean此注释尝试概括 JSF 托管 Bean，以便在 Java EE 中的其他地方使用。
如果您在 EE 6 容器中部署（如果您使用 Tomcat 或其他 servlet 容器，您还可以通过将 Weld jar 添加到您的 Web 应用程序来获取 CDI），那么确实没有理由使用 @javax.faces。 bean.ManagedBean。只需使用
@javax.inject.Named并开始利用 CDI 服务。CDI
CDI 规范的目标之一是将 Web 层和事务服务结合在一起，使开发人员能够轻松地在 Java EE 平台的 Web 应用程序中使用 EJB 和 JSF。
通过 CDI，您可以获得以下服务： 明确定义的生命周期
上下文（受接缝 2 和对话范围影响），依赖注入，松散耦合设施，例如 拦截器，装饰器 和 事件和可移植扩展，允许第三方框架集成到 Java EE 6 环境中，例如 SEAM 3 扩展托管 bean 和 EJB 服务
首先，CDI 适用于任何托管 bean。一些托管 Bean 是 EJB。当我们需要在托管bean中使用EJB服务时，我们只需添加@Stateless、@Stateful或@Singleton注释即可。在我看来，它们充当补充技术，使您只需添加一些注释即可进行灵活且渐进的开发。
那么，我们什么时候应该使用会话 bean 而不是普通的托管 bean？
当您需要一些 CDI 缺少的 EJB 功能时：声明性事务、并发管理、池化、远程或 Web 服务调用、计时器和异步方法调用。
当然，您也可以使用第三方库获取所有方面 - 但这会给您的项目带来额外的复杂性。 恕我直言，EJB 是实现的地方：
最后，如果您需要 EJB 服务，那么您需要一个应用程序服务器（例如 GlassFish 或Jboss AS）如果您只需要CDI服务，您需要一个Servlet容器（例如Tomcat）加上CDI库。
ManagedBean
Java EE 6 has three different ways of defining
beansthat aremanagedin one way or another:@javax.faces.bean.ManagedBeanJSF 2.0 introduced this annotation declaring managed beans in faces-config.xml. This annotation is used to access a bean from the Expression Language.
@javax.inject.NamedIn an EE 6 container CDI this annotation is a built-in qualifier types to provide a name to a bean, making it accessible through EL.
@javax.annotation.ManagedBeanThis annotation attempts to generalize JSF managed beans for use elsewhere in Java EE.
If you deploy in an EE 6 container (If you use Tomcat or another servlet container, you can also get CDI by adding the Weld jar to your web app), then there is really no reason to use
@javax.faces.bean.ManagedBean. Just use@javax.inject.Namedand start taking advantage of CDI sevices.CDI
One of the objectives of CDI specification is to bring together the Web tier and the transactional services, making easy for developers to use EJB along with JSF in web applications of the Java EE platform.
With CDI you have the following services among others : well-defined lifecycle
contexts(influenced by seam 2 and conversation scope),Dependency injection, loose coupling facilities like interceptors, decorators and events and portable extensions, which allows third-party frameworks to integrate in the Java EE 6 environment like SEAM 3 extensionsManaged beans and EJB Services
First of all CDI applies to any managed bean. Some managed beans are EJBs. When we need to use the EJB services in a managed bean, we just add a
@Stateless,@Statefulor@Singletonannotation. IMO they act as complementary technologies allowing you to have a flexible and gradual development just only adding some annotations.So, when should we use a session bean instead of a plain managed bean?
When you need some EJB features that CDI is missing : declarative transactions, concurrency management, pooling, remote or web service invocation ,timers and asynchronous method invokation.
Of course you could also get all aspects using third party libraries - but this would introduce additional complexity to your project. In terms of functionality IMHO EJB are the place to implement :
Finally if you need EJB services then you need an Aplication Server (eg. GlassFish or Jboss AS) if you only need CDI services you need a Servlet Container(e.g Tomcat) plus CDI libraries.
您是否需要 EJB 提供的功能，即安全性和事务管理？如果答案是肯定的，EJB 可能是一个不错的选择。
如果答案是否定的，并且您只需要依赖注入，那么 CDI 可能是一个不错的选择。
您还可以通过其他第 3 方产品获得类似的功能，例如 Spring（依赖注入、Spring 安全性等），但在许多情况下决定是使用一个（EJB）还是另一个（例如 Spring）是之前的问题技能组。
在我看来，如果没有之前的限制，遵守 Java 规范是一项不错的投资。
Do you need the features provided by EJBs, i.e. security and transaction management? If the answer is yes, EJBs might be a good option.
If the answer is no, and you only need dependency injection, CDI could then be a good option.
You can also get similar capabilities with other 3rd party products, like Spring (dependency injection, Spring security, etc), but deciding whether you use one (EJB) or the other (e.g. Spring) is in many of the cases a matter of previous skillset.
In my opinion, if there are no previous constraints, going Java spec compliant is a good investment.
我建议您从 CDI 开始，然后继续进行 EJB（这实际上是在 POJO 之上添加一个注释）（正如所告知的那样 - 事务性、Web 服务、JMX、计时器、EJB 异步）调用）。
开发一个应用程序，其中入口点是 EJB，它包含事务中的调用并允许您定义多个入口点，这是相当合理的。然后，EJB 调用 CDI bean 及其中的业务逻辑。
还值得注意的是 TomEE 是在 Apache 之上开发的经过认证的 Java EE 6 Web Profile雄猫。
I would suggest you to start with the CDI and proceed to the EJB's (which is really adding one annotation on top of your POJO) if the requirements needs them (just as it was told - transactionality, web services, JMX, timers, EJB asynchronous invocations).
It's quite reasonable to develop an application in which your entry point is an EJB which encompasses your call in the transaction and allows you to define multiple entry points. The EJB then invokes the CDI beans with the business logic in them.
It's also worth noticing that the TomEE is a certified Java EE 6 Web Profile developed on top of the Apache Tomcat.