Modèle de conception de DAO

Donc disons que nous avons un couple d'entités que nous voulons persistent à l'aide d'objets DAO. Nous avons donc mettre en œuvre le droit de l'interface de sorte que nous nous retrouvons avec

class JdbcUserDao implements UserDao{
//...
}

class JdbcAddressDao implements AddressDao{
//...
}

Donc, si je veux être en mesure de passer de la persistance des implémentations de JDBC pour JPA (par exemple) et vice-versa, j'aurais besoin d'avoir JPAUserDao et JPAAddressDao... ce qui veut dire que si j'avais 20 entités, et a décidé de passer implémentations(à l'aide de DI conteneur), j'aimerais avoir à passer chaque Jdbc mise en œuvre avec JPA dans le code.

Maintenant, il se pourrait que j'ai mal compris comment DAO fonctionne, mais... Si j'ai juste eu

class JdbcDaoImpl implements UserDao,AddressDao{
//...
}

J'avais alors tous les JDBC mises en œuvre dans une classe, de commutation et d'implémentations serait un morceau de gâteau. Aussi, DaoImpl nombre est égal au nombre d'interfaces Dao. Pourquoi ne pas simplement groupe par la mise en œuvre (jdbc, JTA, JPA...) et tout ce qui est sous classe?

Merci d'avance.

La même raison pourquoi vous n'avez pas de code de votre application dans un grand main() méthode: la séparation des préoccupations. (Btw, personne ne vous empêche de codage d'un résumé JdbcDaoBase contenant le code commun et l'extension que dans votre Dao')
Pourquoi devrait-il être plus facile de remplacer les méthodes de 500 à 1 classe que dans 100 classes?

OriginalL'auteur Mercurial | 2012-03-31