Relation entre le référentiel et l'unité de travail

Je vais implémenter un référentiel, et je voudrais utiliser le modèle UOW car le consommateur du référentiel pourrait effectuer plusieurs opérations, et je veux les valider à la fois.

Après avoir lu plusieurs articles sur le sujet, je ne comprends toujours pas comment relier ces deux éléments, selon l'article, il est fait d'une manière u autre.

Parfois, l'UOW est quelque chose interne au référentiel:

public class Repository
{
    UnitOfWork _uow;

    public Repository()
    {
       _uow = IoC.Get<UnitOfWork>();
    }

    public void Save(Entity e)
    {
        _uow.Track(e);
    }

    public void SubmittChanges()
    {
        SaveInStorage(_uow.GetChanges());
    }
}

Et parfois c'est externe:

public class Repository
{
    public void Save(Entity e, UnitOfWork uow)
    {
        uow.Track(e);
    }

    public void SubmittChanges(UnitOfWork uow)
    {
        SaveInStorage(uow.GetChanges());
    }
}

D'autres fois, c'est l'UOW qui fait référence au référentiel

public class UnitOfWork
{
    Repository _repository;

    public UnitOfWork(Repository repository)
    {
       _repository = repository;
    }

    public void Save(Entity e)
    {
        this.Track(e);
    }

    public void SubmittChanges()
    {
       _repository.Save(this.GetChanges());
    }
}

Comment ces deux éléments sont-ils liés? UOW suit les éléments qui doivent être modifiés, et le référentiel contient la logique pour conserver ces changements, mais ... qui appelle qui? Est-ce que le dernier a plus de sens?

Qui gère également la connexion? Si plusieurs opérations doivent être effectuées dans le référentiel, je pense que l'utilisation de la même connexion et même d'une transaction est plus saine, alors peut-être que vous mettez l'objet de connexion à l'intérieur de l'UOW et que celui-ci à l'intérieur du référentiel a également du sens.

À votre santé

Re: "UOW suit les éléments qui doivent être modifiés, et le référentiel contient la logique pour conserver ces changements, mais ... qui appelle qui?"

Vous comprenez les responsabilités de base de ces classes. Vous dites que chacun des articles que vous avez lu les relie de différentes manières. Cela implique que la décision de "qui appelle qui" dépend de vous.

J'essaierais d'esquisser le problème en termes de `` couches '' tout en étant guidé par les principes de base d'une bonne conception de logiciels tels que la cohésion , le découplage , la réutilisabilité , la testabilité unitaire , etc.

Pour citer Eric Evans Domain Driven Design, (2004) Addison Wesley, pg 69 :

Le principe essentiel [des architectures en couches] est que tout élément d'une couche ne dépend que d'autres éléments de la même couche ou d'éléments des couches "en dessous".

À mon avis, l'UOW et le Repo sont deux classes très différentes qui ont des responsabilités claires et indépendantes. Pour commencer, je ne ferais pas invoquer l'un ou l'autre.

Je pense que vous avez besoin d'une troisième classe client (c'est-à-dire soit a controllerou service class) qui sait vraiment «quand et quoi obtenir» du repo et «quand» pour enregistrer la transaction. Ce client se situe relativement haut dans l'architecture (peut donc connaître plus de classes) et peut faire une certaine orchestration entre les deux.

--------------------------------

         [Client]
           /   \
----------/---- \---------------
         /       \
        V         V
[Unit Of Work]  [Repo]


--------------------------------

Les méthodes sont le plus souvent données à l'interface UOW (qui est normalement construite via une usine).

Vous appelez généralement des méthodes sur une interface UOW à partir de classe (s) de modèle de commande / façade. Étant donné que UOW reporte simplement les E / S de base de données à plus tard (pour vous éviter d'avoir des transactions de longue durée ou plusieurs appels à la base de données qui peuvent être inutiles), travailler avec l'UOW devrait être au même niveau que vous travaillez normalement avec votre base de données.

Microsoft a un article très complet sur le modèle UOW:

http://msdn.microsoft.com/en-us/magazine/dd882510.aspx