En résumé, je décrirais l'impact plus large du pattern repository. Il permet à tout votre code d'utiliser des objets sans avoir à savoir comment les objets sont persistés. Toute la connaissance de la persistance, y compris le mapping des tables aux objets, est en toute sécurité contenue dans le repository.
Très souvent, vous trouverez des requêtes SQL dispersées dans le code source et lorsque vous venez à ajouter une colonne à une table, vous devez chercher dans les fichiers de code pour essayer de trouver les utilisations d'une table. L'impact du changement est considérable.
Avec le pattern repository, vous auriez seulement besoin de changer un objet et un repository. L'impact est très faible.
Peut-être que cela vous aiderait à réfléchir pourquoi vous utiliseriez le pattern repository. Voici quelques raisons :
-
Vous avez un seul endroit pour apporter des modifications à votre accès aux données
-
Vous avez un seul endroit responsable d'un ensemble de tables (habituellement)
-
Il est facile de remplacer un repository par une implémentation factice pour les tests - donc vous n'avez pas besoin d'avoir une base de données disponible pour vos tests unitaires
Il y a d'autres avantages aussi, par exemple, si vous utilisiez MySQL et souhaitiez passer à SQL Server - mais je n'ai jamais vu cela en pratique !