Quelle est votre compréhension du modèle de référentiel?

Question

Je suis en train de rattraper la documentation technique d'un projet que j'ai terminé il y a quelques mois, et je suis sur le point de terminer. J'ai utilisé des dépôts pour extraire la couche d'accès aux données dans les deux et écrivais un court résumé du modèle sur notre wiki au travail.

C'est en rédigeant ce résumé que j'ai réalisé que j'avais adopté une approche légèrement différente la deuxième fois.

On a utilisé une méthode explicite InsertOnSubmit couplée à une unité de travail et à une mise à jour implicite avec les changements de suivi UoW. L'autre avait une méthode Save qui insérait de nouvelles entrées et les mettait à jour (sans UoW).

Quelle approche préféreriez-vous habituellement? Considérons les scénarios CRUD habituels, où devrait se situer la responsabilité de chacun d'entre eux?

Answer 1

Je pense que si un référentiel utilise Unité de travail, la mise en cache, ou d'autres concepts connexes doivent être laissés à l'implémentation. Je préfère que l'interface ressemble à un magasin de données aligné sur le modèle de domaine en question. Alors qu'un référentiel client ressemblerait à quelque chose comme ceci:

interface ICustomerRepository 
{ 
    Customer Load(int id); 
    IEnumerable<Customer> Search(CustomerQuery q); 
    void Save(Customer c); 
    void Delete(Customer c); 
} 

Ceci peut être facilement mis en œuvre par quelque chose comme NHibernate ou NHibernate avec NHibernate.Linq, ou une bibliothèque SQL directe, ou même un XML ou un magasin de fichiers plats . Si possible, j'aime garder le concept de transaction en dehors du référentiel, ou à une portée plus globale afin que les opérations de plusieurs référentiels puissent faire partie d'une seule transaction.