L'alignement du référentiel avec Unit of Work ou ActiveRecord est étroitement aligné

Question

Bien que je ne fasse pas de DDD complet, je trouve le modèle de référentiel attrayant et j'essaie de segmenter les dépôts selon les limites de l'agrégat-racine. J'implémente des dépôts au-dessus de Entity Framework, et ici ObjectContext permet un style d'unité de travail car il suit les modifications apportées aux entités et génère le SQL approprié lorsque SaveChanges est appelé.

Je suis aux prises avec deux approches différentes dans mes référentiels pour savoir quand appeler SaveChanges - et la différence semble être de savoir si j'adopte une sémantique d'unité de travail ou d'enregistrement actif. Si je définir une interface référentiel pour ressembler à ceci:

public interface IRepository<T> 
{ 
    T Get(int id); 
    IList<T> GetAll(); 
    IQueryable<T> Query(); 
    void Delete(T entity); 
    void Add(T entity); 
    IUnitOfWork GetUnitOfWork(); 
} 

et IUnitOfWork être

public interface IUnitOfWork 
{ 
    void SaveChanges(); 
} 

Puis dans la Ajouter (entité T) mise en œuvre, il me semble avoir deux choix:

public void Add(Document entity) 
    { 
     DB.AddToDocumentSet(entity); 
     GetUnitOfWork().SaveChanges(); //delegates to the ObjectContext's SaveChanges 
    } 

ou

public void Add(Document entity) 
    { 
     DB.AddToDocumentSet(entity); 
    } 

Dans le premier cas, la méthode Add du référentiel envoie le SQL à chaque opération. Dans ce dernier cas, le code appelant est responsable de l'obtention de l'unité de travail à partir du référentiel et de l'appel de SaveChanges lorsqu'il le juge approprié. Cela permet à l'unité de travail de s'étendre sur différents référentiels (je m'assure que chaque référentiel obtient la même unité de travail dans sa construction). Mon intuition est que la deuxième approche est plus flexible. L'adoption du modèle d'unité de travail signifie également que les mises à jour des entités sont un peu plus intéressantes dans la mesure où le code appelant met simplement à jour les propriétés des entités renvoyées par les référentiels, puis appelle UnitOfWork.SaveChanges.

Lors de l'utilisation du modèle de référentiel, une approche est-elle généralement favorisée par rapport à l'autre?

Answer 1

Cela dépend de vos besoins en mode de défaillance, ce que vous n'avez pas indiqué. C'est principalement un problème de gestion des pannes qui surviennent pendant votre unité de travail. Vous avez essentiellement deux choix, bien qu'il existe d'autres variantes plus complexes possibles:

1. Enregistrer toutes les modifications survenues pendant l'unité de travail jusqu'à la panne.
2. Annule toutes les modifications survenues pendant l'unité de travail en raison de la défaillance.

Votre première méthode Add est plus approprié pour le scénario 1 et votre deuxième méthode Add est plus approprié pour le scénario 2.

Scénario 1 nécessite probablement du code d'application intelligent pour permettre à l'utilisateur de reprendre au point de défaillance . Le scénario 2 est plus facile à implémenter du côté de l'application, mais peut frustrer l'utilisateur s'il était, par exemple, 8 étapes dans un processus en 9 étapes en cas d'échec.