Le référentiel doit-il avoir une fonctionnalité persistante?

Question

Dans le livre de Fowler "Patterns of Enterprise Application Architecture", il n'y a aucune mention des caractéristiques persistantes du modèle Repository. Par "caractéristiques persistantes", j'entends les fonctionnalités qui mettent à jour, sauvegardent, ajoutent ou suppriment des entités. Juste mécanisme de correspondance pur sur un ensemble d'objets de domaine. De l'autre côté, jetons un oeil à l'article de blog de Mike Hadlow appelé Using the IRepository pattern with LINQ to SQL. Il existe des méthodes concrètes persistantes telles que l'insertion et la suppression.

Alors, comment un modèle de référentiel doit-il être implémenté? Pourriez-vous me dire s'il vous plaît les bonnes implémentations de référentiel "vrai". J'ai de la frustration sur ce sujet.

Merci d'avance! J'espère pour votre aide!

Answer 1

Un référentiel doit simplement agir comme une collection de données en mémoire. La nomenclature que vous choisissez, que ce soit Ajouter ou Insérer, Supprimer ou Supprimer, Sélectionner ou Obtenir, n'est pas importante.

Vous pouvez séparer votre référentiel en 2 interfaces, puis avoir un ReadOnlyRepository pour obtenir/sélectionner des données et un WriteRepository pour ajouter/mettre à jour/supprimer des données. Cela n'a pas d'importance. Ce qui compte, c'est que votre application ou votre code métier utilise le référentiel pour interagir avec les données comme s'il était déjà chargé en mémoire, vous n'avez donc pas besoin de créer des requêtes SQL entremêlées avec le code d'entreprise ou d'application.

Mise à jour

Puisque nous parlons d'un modèle, il n'y a pas une seule interface ou la mise en œuvre du référentiel "true". Il peut y avoir plusieurs implémentations différentes qui suivent toutes un modèle similaire.