JavaEE 6/7中的持久层设计

Question

上次用JBoss 7.1 (Java EE6标准)开发app，用DAOs写了持久层。

首先，我有一个“抽象”的道，它是所有具体道的父亲：

public abstract class AbstractDao<T> {

    private Class<T> entityClass;

    private String defaultSortColumn;

    public AbstractDao(Class<T> entityClass) {
        this.entityClass = entityClass;
        this.defaultSortColumn = "";
    }

    protected abstract EntityManager getEntityManager();

    public void create(T entity) {
        getEntityManager().persist(entity);
    }

    public void edit(T entity) {
        getEntityManager().merge(entity);
    }

    public void remove(T entity) {
        getEntityManager().remove(getEntityManager().merge(entity));
    }

    public T find(Object id) {
        return getEntityManager().find(entityClass, id);
    }

    @SuppressWarnings("rawtypes")
    public List<T> find() {
        CriteriaBuilder cb = getEntityManager().getCriteriaBuilder();
    CriteriaQuery cq = cb.createQuery();
        Root from = cq.from(entityClass);
        cq.select(from);
        return getEntityManager().createQuery(cq).getResultList();
    }

    @SuppressWarnings("rawtypes")
    public int count() {
        //...
    }

}

然后，我的域中的每个DB实体都有一个dao实现。

它们都非常相似，它们只是为比通常的“crud”操作更复杂的查询添加方法。

下面是一个示例：

@Stateless
public class ShopDao extends AbstractDao<Shop> {

    @Inject
    private EntityManager em;

    @Override
    protected EntityManager getEntityManager() {
        return em;
    }

    public ShopDao() {
        super(Shop.class);
    }
}

如您所见，我的Dao是无状态EJB。

这种方式使我的应用程序工作，但...当我必须创建一个新的实体时，我必须创建实体本身和DAO。有点多余是不是？但是，我想不出更好的方法，因为我经常需要对特定的实体进行复杂的查询。

问题是：

> < li>

这是最佳做法吗？我还能如何设计我的持久层？

对于一个道琼斯来说，成为一个EJB有好处吗？

我在客户端（JSF 控制器）中进行了验证。它应该在持久层吗？如何？

在服务层类中使用原始EntityManager是否更好，避免DAO？

编辑

有没有办法避免每个表都有一个dao？

Answer 1

部分答案：

我认为这是一个很好的做法，但就我而言，我也会有一个包含部分逻辑的实体服务层。通常我使用隐藏道的EntityService，它负责逻辑/验证/…

但是如果你使用Spring，你可以（应该？）使用Spring数据JPA，它有一个非常好的数据层。

不要在持久性层中嵌入验证。仅保留此图层以供数据库访问。例如，应在服务图层中（或根据您的项目在视图图层中）中完成验证。并将实体管理器保留在持久性层中，因为它们粘在一起。

Answer 2

我建议完全放弃DAO。你必须问自己，你需要它们做什么？

1）抽象DAO类实际上什么也不做，然后将调用委托给实体管理器，因此您自己创建了一个＜code＞edit＜/code＞方法来替换＜code＞merge＜/code＞方法，这不仅是不必要的，而且还使代码更难阅读，因为必须有人检查＜code＞edit＜/code＞方法的功能。

第二）您没有显示具体DAO类的功能，但很可能这可以在实体本身（因为实体是一个业务对象，而不仅仅是一个哑数据容器）或控制器（因为它们控制实体之间的交互，例如无状态EJB）中完成。

在你的应用程序中总是从简单开始，不要从设计一个层开始，你可能需要一些时间，但这会使一切变得更复杂。

Answer 3

“这是最佳实践吗？我还能怎么设计我的持久层？”

你的方法看起来不错。有些人喜欢让DAO层完全独立于其他层。这种方法的优点是，您可以在其他地方重用DAO层，而且在应用服务器之外测试DAO也更容易。我不太支持这种方法，因为它经常是一种矫枉过正的做法——EJB方法只是DAO层的一层薄薄的包装。EJB也很容易在应用服务器之外测试(Spring提供了所有需要的测试工具)。所以，只要你不打算在你的EJB实现更复杂的商业逻辑，我会赞同你的方法。

请继续阅读以了解更多详细信息…

“DAO做EJB好吗？”

更准确地说，在您的方法中，EJB不是Dao，因为它们也管理事务，可以负责业务逻辑的其他非数据库元素。EJB还为您的应用程序提供外部接口。从技术上讲，EntityManager是您的DAO，EJB使用它来实现所有需要的业务逻辑。

“我在客户端（JSF控制器）进行了验证。它应该在持久层吗？怎么做？”

在 Java EE 6 中，您可以利用 Bean 验证技术 - 在模型级别定义验证规则（作为实体字段上的注释），这些规则由持久性层和 JSF Web 层强制执行。

"将原始的EntityManager放在服务层类中，避免使用Dao，会不会更好？"

据我所知，你想摆脱EJB？您可以这样做，但是您需要自己管理事务(在简单的情况下，这不是什么大事)。无状态本地接口或无接口EJB现在相当轻量级，所以没有很好的理由去避免它们。作为替代，你可以使用Spring框架支持JPA。