我正在使用REST Web服务设计一个非常简单的Web应用程序，该服务利用JPA与PostgreSQL数据库进行交互并在TomEE中运行。
我不相信我有需要（或希望）手动管理EntityManager的生命周期，因此我计划通过使用Container Managed EntityManagers（可能是Transaction Scoped）将这些杂项卸载到TomEE上。
我不相信我有需要（或希望）手动管理Container Managed EntityManagers所需的JTA交易。
最后，我计划使用DAO类将任何查询与作为我的REST Web服务的业务逻辑分开。
我是每个DAO类的最佳选择，是使用@PersistenceContext批注获取对EntityManager的引用的EJB吗？如果是这样，DOA应该是什么类型的EJB？我看过一些示例/博客建议无状态，有状态，单一，甚至完全忘记DAO，将EntityManager注入Web服务本身。处理这个问题的最佳方法是什么？
答案 0 :(得分：0)
每个DAO都应该是一个无状态会话Bean，其中数据库引用被注入。
使用GenericDAO通过EntityManager执行CRUD操作会更好，以避免在EJB周围复制代码。
如果必须调用某些服务，我通常更喜欢为每个Ws客户端创建一个EJB。
如果要提供Ws服务器，我总是注入我需要的EJB实例而不是注入EntityManager实例，因为拥有一个访问点是一件好事。
答案 1 :(得分：0)
使类成为EJB将为类提供EJB和Container管理的一些功能，例如事务管理，线程安全，安全性等。
在 Ejb in Action 一书中，据说建议使用一个与EntityManager一起使用的简单DAO类（非EJB）。 DAO类不应该参与事务管理和EJB所具有的其他功能，相反，应始终存在使用DAO类的EJB（使用@Inject注释），而其他服务（如REST或SOAP Web服务）应该调用使用的EJB我们需要的DAO。
将所有类（如DAO类和Utility类）转换为EJB，将给容器带来负担，并且会使管理所有EJB变得更加困难。