我正在做一个项目，我们需要决定如何公开我们的持久层。
目前有两个选项:
1) 使用普通的 DAO。这些将实现一个接口(interface)并被注入(inject)(可能使用 Weld)在作为 EJB 的业务组件中。在内部，他们会使用 JPA/Hibernate 来实现持久化。
2) 与其使用 Weld 注入(inject) DAO，不如将它们实现为 EJB，并在业务组件中注入(inject) @EJB。
当我们不使用持久层的功能(例如事务管理 - 业务层处理这个)时，将 EJB 用于持久层真的有意义吗？
使用 EJB 而不是 Weld(或反之)是否有任何性能损失？
您认为哪种选择最好？
最佳答案
将 EJB 用于基于 JPA 的 DAO 是天作之合。
如果事务通常在您的业务层(也就是您提到的 EJB)中开始，事务自然会传播到它们。如果你想单独使用 DAO，那么将为你启动一个事务。您现在可能不会使用此功能，但如果您需要它，它是完全免费的。
此外，如果您需要在其自己的事务中执行单个操作，那么当您的 DAO 是基于 EJB 时，这是微不足道的。
用 DAO EJB 注入(inject)您的业务 EJB 可能具有潜在的性能优势。由于只注入(inject)委托(delegate)给池化实例的 stub ，因此注入(inject)相对便宜。您可以将许多 DAO 注入(inject)您的业务 EJB，这些 DAO 可能是每次调用都必需的，也可能不是全部。我不是 100% 确定 CDI 具有完全相同的功能。它当然有范围界定和对话，但并没有真正 stub 以委托(delegate)给池。
如果您需要 JPA 的扩展持久性上下文，那么有状态 session bean 实际上就是为此而创建的，否则无状态 session bean 将用于 DAO。
也就是说，CDI 是更现代的组件模型，目前的想法似乎是 EJB 最终将被改造为一组 CDI 注释。现在开始建立 CDI 代码库和知识实际上可能是一个长期的战略利益，因此预示着 CDI。
因此，更直接地回答您的问题:是的，将 EJB 用于持久层是有意义的，但是 EJB 或 CDI 在这里绝对不是错误的选择。
关于dependency-injection - EJB3 与数据访问对象，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4950693/