1

ここの投稿によると、次の 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を単純に拡張することもできましたが、 MongoDBからJDBCなどBasicDAO<T, K>に簡単に変更することはできませんでした。

4

1 に答える 1

2

Spring または Guice を検討することをお勧めします。これを依存性注入と呼んでいるため、「クライアント」は依存性のルックアップ/インスタンス化を実行する責任がありません。これらのコンテナは「Bean」を作成し、「クライアント」オブジェクトに必要な正しいものを注入するため、クライアント オブジェクトは DAO の取得場所や使用する実装について心配する必要がありません。

また、DI の世界では、実装ごとに異なる Bean の作成方法を使用しても害はありません。これらの「汚れた」ものは一元化されています (たとえば、Spring の場合のアプリ コンテキスト構成)。

于 2011-11-16T04:38:08.760 に答える