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

Question

Je suis en train de mettre à jour la documentation technique pour un projet que j'ai achevé il y a quelques mois et dont je suis sur le point de le terminer. J'ai utilisé des référentiels pour résumer la couche d'accès aux données dans les deux et je rédigeais un bref résumé du motif sur notre wiki au travail.

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

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

Quelle approche privilégieriez-vous généralement? Considérez 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 l’Unité de Travail, la mise en cache ou tout autre concept associé, doit être laissé à l’implémentation. Je préfère que l'interface ressemble à un magasin de données aligné sur le modèle de domaine utilisé. Pour qu'un référentiel client ressemble à ceci:

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

Ceci peut être facilement implémenté avec quelque chose comme NHibernate, ou NHibernate avec NHibernate.Linq, ou une bibliothèque SQL directe, ou même un magasin de fichiers XML ou à plat. Si possible, j'aime bien garder le concept de transaction en dehors du référentiel ou à un niveau plus global afin que les opérations de plusieurs référentiels puissent faire partie d'une même transaction.