我正在开发一个项目，我们需要决定如何公开我们的持久层。
目前桌面上有两个选项：
1）使用普通DAO。这些将实现一个接口，并在作为EJB的业务组件中注入（可能使用Weld）。在内部，他们会使用JPA / Hibernate来保持持久性。
2）不是使用Weld注入DAO，而是将它们实现为EJB，并在业务组件中注入@EJB。
当我们不使用其功能时，将EJB用于持久层是否真的有意义（例如，事务管理 - 业务层处理此问题）？
使用EJB over Weld（或反过来）是否有任何性能损失？
您认为哪种选择最好？
答案 0 :(得分：8)
将EJB用于基于JPA的DAO非常自然。
如果事务通常在您的业务层（也就是您提到的EJB）中启动，那么事务将自然地传播给它们。如果您想单独使用DAO，那么将为您启动交易。您现在可能不会使用此功能，但如果您需要它，它将完全免费。
此外，如果您需要在自己的事务中进行单个操作，那么当您的DAO基于EJB时，这是微不足道的。
使用DAO EJB注入业务EJB可能具有潜在的性能优势。由于只注入了代表池化实例的存根，因此注入相对便宜。您可以为业务EJB注入许多DAO，这些DAO可能是也可能不是每次调用都需要的。我不是100％肯定CDI具有这种完全相同的功能。它当然有范围和对话，但不是真正的存根来委托池。
如果您需要JPA的extended persistence context，那么实际上会为此创建有状态会话bean，否则无状态会话bean将用于DAO。
也就是说，CDI是更现代的组件模型，目前的想法似乎是EJB最终会被改装为一组CDI注释。现在开始建立CDI代码库和知识实际上可能是一个长期的战略利益，因此是CDI的预兆。
所以更直接地回答你的问题：是的，将EJB用于持久层是有意义的，但EJB或CDI在这里绝对不是错误的选择。