Quel motif de conception pour localiser mon IUnitOfWork?

Question

J'ai implémenté un modèle de référentiel avec une ignorance de persistance. L'implémentation du référentiel n'interagit qu'avec mes objets d'entité, IUnitOfWork et ITable<T>. L'intention est que le IUnitOfWork ne soit pas réutilisé mais représente une seule transaction. Jusqu'à présent, j'ai implémenté en-mémoire ainsi que Linq-to-Sql des versions IUnitOfWork et ITable<T>.

Mon problème est que, en raison de l'injection IUnitOfWork dans le référentiel, je finis avec besoin de savoir comment instancier une nouvelle IUnitOfWork où que le dépôt est utilisé. Puisque c'est la pièce principale qui est supposée être connectable, j'ai l'impression d'avoir fait quelque chose de mal. Le modèle d'utilisation général est quelque chose comme ceci:

FooUnitOfWork unitOfWork = new FooUnitOfWork(); 
Repository repos = new Repository(unitOfWork); 
// ...act upon repos 
unitOfWork.Save(); 

Maintenant, il semble que j'ai besoin d'un autre modèle pour permettre à chaque utilisation du référentiel dans l'application pour obtenir l'unité correcte du travail (par exemple en mémoire, L2S, etc.).

Quel est le modèle le plus approprié pour cela? J'ai regardé Fowler's discussion on the topic mais aucun de ses exemples ne semble être un ajustement propre. Je me sens déjà comme la quantité d'abstraction que j'ai est plus que ce que je voudrais pour construire encore une autre indirection semble excessive. À l'heure actuelle, je me tourne vers un fournisseur d'application qui peut être configuré pour produire le bon IUnitOfWork. Suis-je hors-base ou est-ce ce qui est nécessaire pour être vraiment agnostique de mise en œuvre?

Answer 1

Mise à jour: alors que cela ne s'est pas vraiment effondré, il a fini par produire un conteneur IoC pauvre. J'ai fini juste de remplacer tous ces:

UnitOfWorkFactory.Create(); 

avec la Common Service Locator généralisée mise en œuvre:

Microsoft.Practices.ServiceLocation.ServiceLocator.Current.GetInstance<IUnitOfWork>(); 

Cela m'a permis de créer une bibliothèque qui utilise l'injection de dépendance sans forcer tous les utilisateurs à utiliser le même cadre IoC .

---

Peut-être que je devrais utiliser une usine très simple où je peux définir un rappel? Il pourrait avoir un ensemble de méthodes statiques dessus comme ceci:

public static class UnitOfWorkFactory 
{ 
    private static Func<IUnitOfWork> FactoryMethod; 

    public static IUnitOfWork Create() 
    { 
     if (UnitOfWorkFactory.FactoryMethod == null) 
     { 
      throw new InvalidOperationException("..."); 
     } 

     return UnitOfWorkFactory.FactoryMethod(); 
    } 

    public static void SetFactoryMethod(Func<IUnitOfWork> factory) 
    { 
     UnitOfWorkFactory.FactoryMethod = factory; 
    } 
} 

Où cela se brise-t-il?

Answer 2

Je suggère d'utiliser un modèle Vistor pour découvrir les implémentations de l'interface IUnitOfWork. A l'intérieur de l'instance repo, une fabrique de découverte trouve le worker et le crée.