Gon*_*gui 2 dao dependency-injection ejb-3.0
我正在开发一个项目,我们需要决定如何公开我们的持久层.
目前桌面上有两个选项:
1)使用普通DAO.这些将实现一个接口,并在作为EJB的业务组件中注入(可能使用Weld).在内部,他们会使用JPA/Hibernate来实现持久性.
2)不是使用Weld注入DAO,而是将它们实现为EJB,并在业务组件中注入@EJB.
当我们不使用其功能时(例如,事务管理 - 业务层处理此问题),将EJB用于持久层是否真的有意义？
使用EJB over Weld(或反过来)是否有任何性能损失？
您认为哪种选择最好？
将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在这里绝对不是错误的选择.