问题描述
我正在做一个项目，我们需要决定如何公开持久层。
I am working on a project where we need to decide how we are going to expose our persistence layer.
表上当前有两个选项：
1）使用普通DAO。这些将实现一个接口，并被注入（可能使用Weld）在作为EJB的业务组件中。在内部，他们将使用JPA / Hibernate进行持久化。
1) Use plain DAOs. These would implement an interface and be injected (probably using Weld) in the Business Components which are EJBs. Internally they would use JPA/Hibernate for persistence.
2）不是使用Weld注入DAO，而是将它们实现为EJB，并在业务中注入@EJB。组件。
2) Rather than injecting the DAOs using Weld, they would be implemented as EJBs, and injected with @EJB in the Business Components.
在我们不使用EJB的功能（例如事务管理-业务层处理此功能）时，将EJB用于持久层真的有意义吗？
Does it really make sense to use EJBs for the persistence layer when we are not using its capabilities (e.g. transaction management - business layer deals with this)?
在Weld上使用EJB是否会降低性能（或者相反）？
Is there any performance penalty in using EJB over Weld (or the other way round)?
您会选择哪种选择？
推荐答案
为基于JPA的DAO使用EJB是很自然的选择。
Using EJBs for a JPA based DAO is a perfectly natural fit.
如果事务通常在您的业务层中开始（您所说的也是EJB），则事务自然会传播到它们。如果您想单独使用DAO，则将为您启动事务。您可能现在不使用此功能，但是如果需要它会完全免费。
If the transaction normally starts in your business layer (which are also EJBs as you mention) the transaction will naturally propagate to them. Should you ever want to use the DAO separately, then a transaction will be started for you. You may not use this feature now, but it comes totally free should you ever need it.
此外，如果您需要在其自己的事务中进行单个操作，则当您的DAO基于EJB时，这是微不足道的。
Also, should you ever need to a single operation in its own transaction, then this is trivial when your DAOs are EJB based.
用DAO EJB注入业务EJB可能具有潜在的性能优势。由于仅注入了代表池实例的存根，因此注入相对便宜。您可以为您的业务EJB注入许多DAO，这些DAO可能对于每个调用都必需，也可以不是全部。我不是100％确信CDI具有完全相同的功能。它当然具有作用域和对话，但实际上并没有存根委托给池。
Injecting your business EJBs with the DAO EJBs may have a potential performance advantage. As only stubs are injected that delegate to pooled instances, injection is relatively cheap. You can inject your business EJBs with many DAOs that may or may not all be necessary for every call. I'm not 100% sure CDI has this exact same capability. It of course has scoping and conversations but not really stubs to delegate to a pool.
您是否需要JPA的扩展持久性上下文，那么实际上是使用有状态会话Bean，否则将使用无状态会话Bean进行DAO。
Should you ever need JPA's extended persistence context, then the stateful session bean is practically made for that, otherwise the stateless session bean would be used for DAOs.
也就是说，CDI是更现代的组件模型和当前的想法似乎是EJB最终将作为一组CDI注释进行改进。现在开始建立CDI代码库和知识实际上可能是一项长期的战略利益，因此对CDI来说是个好兆头。
That said, CDI is the more modern component model and the current thinking seems to be that EJB will eventually be retrofitted as a set of CDI annotations. Starting to build up a CDI codebase and knowledge now may actually be a long term strategic benefit, and thus bodes for CDI.
因此，直接回答您的问题：是的将EJB用于持久层很有意义，但是EJB或CDI都不是错误的绝对选择。
So to answer your question more directly: yes it makes sense to use EJBs for the persistence layer, but neither EJB or CDI are absolutely a wrong choice here.
这篇关于EJB3与数据访问对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！