Jpa 没有EJB的javaee-DAO

是否可以在JavaEE环境中创建一个DAO，它使用JPA，但不需要是无状态bean？我这样问是因为我有大量的EJB，只是因为我需要DAO中的一些@Resources，即

EntityManager

等等

在大型项目中，作为简化DAO的一种方法，您会推荐什么？在我看来，为DAO提供一个完整的EJB（而不是一个简单的对象）是非常困难的

---

DAO既可以从其他EJB访问，也可以从servlet访问。

您可以根据需要实现POJO。但是DAO需要一个

EntitManager

，它必须来自某个地方。或者

您可以在POJO中使用

InitialContext#lookup

将其传递给POJO的构造函数

您必须注意，

InitialContext#lookup

仅在父EJB声明了对实体管理器的依赖关系时才起作用，即使它不使用它

这是否值得麻烦是一个判断。本地EJB非常便宜，拥有多个EJB对应用服务器来说不是问题。这更像是一个开发人员可以理解的问题。（见附件）

---

另一个问题是。有了EJB3，它们的逻辑层变得非常薄，值得思考其利弊

将

EntityManager

与

UserTransaction

一起注入其他类型的bean（例如CDI管理的bean），然后手动管理事务是可能的，但不推荐这样做

在JavaEE7中，JTA1.2为声明性事务提供了与CDI兼容的扩展，就像EJB一样，但目前还没有任何JavaEE7的最终版本

在我看来，为DAO提供一个完整的EJB（而不是一个简单的对象）是过分的

你为什么这么想？“完整的”EJB可能比任何其他替代方案都要轻量级，而且几乎可以肯定比任何基于

EntityManager的自制产品都要轻量级

不要忘记EJBbean会自动共享它们的资源，并且注入点只获取代理。如果您主要使用无状态EJB bean，那么这些代理类似于URL，而不是“真正的”bean。这使得无状态和本地ejbbean的注入非常轻量级

这意味着，如果您有一个给定的服务，其中您注入（比如）10个DAO，每个DAO都有一个注入的
EntityManager
，并且在给定的调用过程中调用了3个DAO，那么实际只使用了3个bean，只有1个
EntityManager
实例。它确实相当有效。
为什么“不推荐”使用CDI？因为事务（由EJB自动管理）-如果我使用DAO，它只是来自另一个EJB的对象，它不应该仍然有事务（由EJB启动）吗？根据我的经验，尤其是Glassfish，您拥有的EJB越多，appserver就越不稳定。@bozo如果您总是在EJB上启动调用，CDI bean中的EM确实应该加入事务，但是您的代码将高度依赖于调用它的人，您将无法控制显式启动新事务（例如，REQUIRES_new）@bozo>
根据我的经验，尤其是Glassfish，您拥有的EJB越多，appserver的稳定性就越差
——所以这似乎是您问题背后的“动机”，对吗？你为什么这么想？我主要在大型项目中使用JBoss，在一些项目中使用了数百个EJB bean，我从未遇到过任何可能归因于拥有许多EJB bean的不稳定性。我也从来没有在任何文学作品中听说过这一点，也从来没有遇到过其他人如此提及这一点。