Question

根据我的帖子here，我有以下DAO层次结构：

GenericDAO.java

public interface GenericDAO<T, K> {
    public K insert(T object);
    public void remove(K objectId);
    // extensible
}

GenericDAOMongoDBImpl.java

public class GenericDAOMongoDBImpl<T, K> extends BasicDAO<T, K> implements GenericDAO<T, K> {
    public GenericDAOMongoDBImpl(Class<T> entityClass, Mongo mongo, Morphia morphia, String dbName) {
        super(entityClass, mongo, morphia, dbName);
    }

    public K insert(T object) {
        // TODO Auto-generated method stub
        return null;
    }

    public void remove(K objectId) {
        // TODO Auto-generated method stub
    }
}

ObjectDAO.java

public interface ObjectDAO extends GenericDAO<Object, ObjectId> {
}

ObjectDAOMongoDBImpl.java

public class ObjectDAOMongoDBImpl extends GenericDAOMongoDBImpl<Object, ObjectId> implements ObjectDAO {
    public ObjectDAOMongoDBImpl(Class<Object> entityClass, Mongo mongo, Morphia morphia, String dbName) {
        super(entityClass, mongo, morphia, dbName);
    }
}

我对如何使用ObjectDAO感到困惑？在这个时间点，我认为工厂方法是过度的。因此，从客户端简单地构造DAO更有意义：

ObjectDAOMongoDBImpl objectDAO = new ObjectDAOMongoDBImpl(clazz, mongo, morphia, dbName);

由于clazz是动态的，它可能已经证明是一个噩梦，试图改变工厂方法接受一个参数，一路上打破我的通用接口。

有更清洁的方式吗？我本可以简单地扩展 morphia 提供的BasicDAO<T, K>，但这不允许我轻易地从 MongoDB 更改为 JDBC 等等。

Answer 1

我建议你看看Spring或Guice。这就是我们所谓的依赖注入，因此“客户端”将不负责为其依赖项执行查找/实例化。这些容器将创建“bean”并在“client”对象中注入您需要的正确的bean，这样您的客户端对象就不必担心DAO的位置或应该使用的实现。

在DI世界中，为不同的实现提供不同的bean创建方法并没有坏处。这些“脏”的东西是集中的（例如，在Spring的情况下在App Context配置中）。

如何在没有工厂的情况下拨打DAO？

1 个答案: