1

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

通用DAO.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
    }
}

对象DAO.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是动态的，它可能被证明是一场噩梦，试图改变工厂方法来接受一个参数，一路破坏我的通用接口。

有没有更清洁的方法？我本可以简单地扩展提供的morphiaBasicDAO<T, K>，但这不会让我轻松地从MongoDB更改为JDBC等。

4

1 回答 1

2

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

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

于 2011-11-16T04:38:08.760 回答