如何在沒有工廠的情況下調用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是動態的，它可能會被證明是一場噩夢試圖改變工廠方法接受的說法，打破我的通用接口。

有沒有更清潔的方法？我可以簡單地擴展提供BasicDAO<T, K>的嗎啡，但這不會讓我輕易改變從MongoDB的到JDBC等

來源

2011-11-16 wulfgarpro

我會建議你看看春天或吉斯。這就是我們所說的依賴注入，因此「客戶端」不會負責爲它們的依賴項執行查找/實例化。這些容器將創建「bean」並在你的「客戶」對象中注入所需的正確對象，這樣你的客戶對象就不必擔心DAO的獲取位置或應該使用哪個實現。

而在DI世界中，對於不同的實現來說，爲不同的bean創建方法並沒有什麼壞處。這些「髒」的東西是集中的（例如在Spring的情況下在App Context配置中）。

來源

2011-11-16 04:38:08

所以你說我的方法很好（沒有_factory method_，我應該只使用_Guice_之類的東西，而不是在客戶端代碼中定義具體的實現類？ – wulfgarpro

如何在沒有工廠的情況下調用DAO？

回答

相關問題