我的 DAO 策略可以吗？

Question

我正在使用休眠。 问题在底部。

目前的策略

很简单。

首先，我有一个基本的Dao。

public class Dao<T> {
    private Class<T> persistentClass;
    private Session session;

    public Dao(Class<T> persistentClass) {
        this.persistenClass = persistentClass;
        this.session = HibernateUtil.getCurrentSession();
    }

它作为一个基类很好，它将最常见的方法传递给它的 Session。

    public T get(Serializable id) {
        @SuppressWarnings("unchecked")
        T t = (T) this.session.get(this.persistentClass, id);

        return t;
    }

    protected Criteria getCriteria() {
        return this.session.createCriteria(this.persistentClass);
    }

当需要对模型使用查询时，它会进入该模型的特定 DAO，该 DAO 继承自 Dao。

public class DaoTask extends Dao<Task> {
    public DaoTask() {
        super(Task.class);
    }

    public List<Task> searchActiveTasks() {
        @SuppressWarnings("unchecked")
        List<Task> list = (List<Task>) this.getCriteria()
            .add(Restrictions.eq("active", true))
            .list();

        return list;
    }
}

这种方法一直很有效。

然而...

然而，今天我发现很多时候一个实例需要重新附加到 Session 并且最终会出现类似于以下内容的行：

new Dao<Book>(Book.class).update(book);

...我发现这很糟糕，因为

1. 我不不喜欢指定多余的 Book.class
2. 如果出现 DaoBook，这个构造将变得过时。

于是我把 Dao 变成了一个抽象类，然后继续重构旧代码。

问题

为了从代码库中删除 Dao 引用，我想到了两种方法：

1. 为每个需要附件的类创建特定的 DAO，这会生成许多几乎空的 DaoBook< /code>s 和排序。
2. 创建一个拥有 Dao

我倾向于选择#2，但我认为这个“AttacherDao”模式可能不好，所以我想听听你的意见。

#2 有什么缺点吗？ 另外，您觉得“目前的策略”有什么问题吗？

Answer 1

我们的方法是为每个持久类提供一个 DAO 对象（从 commonDao 派生）。 实际上我们为这个DAO类定义了接口，每个DAO决定开放哪些接口。

使用以下代码，用户无法删除PersistentClass。

interface PersistentClassDao {
    void save(PersistentClass persistentObject);    
}

Class PersistentClassDaoImpl extends CommonDao implements PersistentClassDao {
        void save(persistentObject) {
    persist(persistentObject);
}

尽管它有一些额外的开销，但这种方法有助于在公开接口之前对适当的代码进行单元测试。

Answer 2

我们选择了与 lud0h 类似的方法，但有以下变化：

abstract class<T extends IModelObject> JdbcCrudDao<T>{

   void create(T dbo){}
   T findByFoo(String foo){}
   void update(T dbo){}
   void delete(T dbo){}

}

class BarDao extends JdbcCrudDao<Bar>{

}

但是，不同之处在于我们通过门面有选择地公开 Dao 上的方法，并仅转发那些我们绝对必须的方法。

class BarController implements IController{

    private static final BarDao dao;
    // ...

    void update( IBar bar ){
       dao.update(bar);
    }

}

所有这一切中唯一的缺点是，如果您希望将数据库密钥隐藏在接口类型后面（我们就是这样做的），则需要进行一些转换，但与替代方案（Daos 之外的数据库代码）相比，这是一个相当小的不便。

Answer 3

几个问题

1. 您是否经常创建 DAO 来完成一项任务，或者这些任务是长期存在的？
2. 使用静态函数怎么样？ 显然，您的 Book 对象可以在没有 Book.class 引用的情况下将 DAO 函数绑定到...

否则，我有点担心保留会话对象而不是获取当前会话的任何内容 - 这不是被认为“不好”吗？ “拥有长期存在的会话对象？ 我不是 DAO 的大师，所以也许我在这里遗漏了一些东西。