EJB3 与数据访问对象答案

【问题标题】：EJB3 vs Data Access ObjectsEJB3 与数据访问对象
【发布时间】：2011-02-09 21:28:55
【问题描述】：

我正在做一个项目，我们需要决定如何公开我们的持久层。

目前有两种选择：

1) 使用普通的 DAO。这些将实现一个接口并在作为 EJB 的业务组件中注入（可能使用 Weld）。在内部，他们会使用 JPA/Hibernate 来实现持久性。

2) 不是使用 Weld 注入 DAO，而是将它们实现为 EJB，并在业务组件中注入 @EJB。

当我们不使用持久层的功能（例如事务管理 - 业务层处理此问题）时，将 EJB 用于持久层真的有意义吗？

在 Weld 上使用 EJB（或相反）是否有任何性能损失？

你认为哪个选项最好？

【问题讨论】：

您是否在“容器内”部署？哪个容器？使用 EJB3可以潜在地使部署更加直接。使用 JEE6 恕我直言，几乎没有理由避免 EJB 和许多情况 for 使用它。价值 2 便士。
那些你根本不需要额外的 EJB 特性（例如安全性、事务......）的情况呢？我认为在这些情况下，CDI 是一个不错的选择？

标签： dependency-injection ejb-3.0 dao

【解决方案1】：

将 EJB 用于基于 JPA 的 DAO 是天作之合。

如果事务通常在您的业务层（您提到的也是 EJB）中开始，则事务自然会传播给它们。如果您想单独使用 DAO，那么将为您启动一个事务。您现在可能不会使用此功能，但如果您需要，它会完全免费。

此外，如果您需要在自己的事务中执行单个操作，那么当您的 DAO 基于 EJB 时，这很简单。

使用 DAO EJB 注入您的业务 EJB 可能具有潜在的性能优势。由于只注入了委托给池实例的存根，因此注入相对便宜。您可以将许多 DAO 注入您的业务 EJB，这些 DAO 可能对每次调用都是必需的，也可能不是全部必需的。我不是 100% 确定 CDI 具有完全相同的功能。它当然有范围界定和对话，但没有真正的存根委托给池。

如果您需要 JPA 的 extended persistence context，那么有状态会话 bean 实际上就是为此而设计的，否则无状态会话 bean 将用于 DAO。

也就是说，CDI 是更现代的组件模型，目前的想法似乎是 EJB 最终将被改造为一组 CDI 注释。现在开始建立 CDI 代码库和知识实际上可能是一项长期战略利益，因此预示着 CDI。

所以要更直接地回答您的问题：是的，将 EJB 用于持久层是有意义的，但是 EJB 或 CDI 都不是绝对的错误选择。

【讨论】：

非常详细的回复。我主要关心的是：如果我每个表有一个 DAO，那么创建一个 DAO 实例池可能有点太多了 - 使用 EJB 3.1 中的新 @Singleton bean 是否有意义？此外，我没有在 DAO 级别使用事务，也不打算使用它们以及任何其他 EJB 功能（例如安全性）。根据我的阅读，这应该是使用 EJB 还是 CDI 之间的决定因素。你怎么看？
如果我每个表有一个 DAO，那么创建一个 DAO 实例池可能有点过分 - 你不必担心这个。实例将按需创建，而不是预先创建。这意味着您可以为您的业务 bean 注入许多不同的 DAO，只会注入存根，并且只有在您实际访问存根时才会创建实例。之后，实例将保存在池中。如果您担心池，您可以调整它（最大保持活动，最大实例保持），但这在实践中几乎不是问题。