アプリケーション全体ですべてのDAOインターフェイスを実装する単一のクラスを実装することは、どちらかというと悪い設計になります。
より多くの典型的なパターンは、これらのベースクラスは、発見/取得/リードのようなメソッドが含まれている/店舗/存続を保存し、更新/修正するなどJDBCBaseDAO、（もしばしばGenericDAO呼ばれる）BaseDAOインタフェースを持っているとJPABaseDAOを持つことです削除/削除/パージを行います。 UserDAO等
特定DAOインターフェイスは、次いで、BaseDAOから継承しJPAUserDAO等具体的な実装は、JPABaseDAOから延びています。
BaseDAOインタフェースは次のようになります。
public interface BaseDAO <T> {
T getByID(Long ID);
T save(T type);
T update(T type);
void delete(T type);
}
そしてUserDAOインタフェース：このインタフェースを実装するJPABaseDAOの
public interface UserDAO extends BaseDAO<User> {
List<User> getAllAuthorized();
}
ベア骨例：
@Stateless
public class JPABaseDAO<T> implements BaseDAO<T> {
@PersistenceContext
private EntityManager entityManager;
private final Class<T> entityType;
@SuppressWarnings("unchecked")
public JPABaseDAO() {
this.entityType = ((Class<T>) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0]);
}
@Override
public T getByID(Long ID) {
return entityManager.find(entityType, ID);
}
@Override
public T save(T type) {
return entityManager.persist(type);
}
@Override
public T update(T type) {
return entityManager.merge(type);
}
@Override
public void delete(T type) {
entityManager.remove(entityManager.contains(type) ? type : entityManager.merge(type));
}
}
そして、いくつかのサンプルUserDAOそれから継承する実装：実際には
@Stateless
public class JPAUserDAO extends JPABaseDAO<User> implements UserDAO {
@PersistenceContext
private EntityManager entityManager;
@Override
public List<User> getAllAuthorized() {
return entityManager.createNamedQuery("User.getAllAuthorized", User.class)
.getResultList();
}
}
基底クラスは、多くの場合、インスタンスは、エンティティがAuditableインターフェースのいくつかの種類を実装している場合のチェック、およびそれを自動的に変更された日付とユーザーを設定するために、透過的に他のいくつかのことを行うことができます
EJBを使用してDAOを実装する場合、実装を変更する1つの戦略は、すべてのJDBC実装を1つのパッケージに入れ、すべてのJPA実装をもう1つのパッケージに入れることです。次に、ビルドには1つの実装パッケージのみを含めます。
あなたは一つの大きな 'メイン（）'メソッドにアプリケーションをコーディングしない理由と同じ理由：関心事の分離。 （誰もあなたが普通のコードを含む抽象的な 'JdbcDaoBase'をコード化し、あなたの' Dao'でそれを拡張するのを防ぎません） – rsp
100クラスより1クラスで500メソッドを置き換える方が簡単なのはなぜですか？ –