Quel modèle de conception pour localiser mon IUnitOfWork?

Question

Je l'ai mis en place un modèle référentiel avec l'ignorance de persistance. La mise en œuvre du référentiel interagit uniquement avec mes objets d'entité, interfaces IUnitOfWork et ITable<T>. L'intention est que le IUnitOfWork n'est pas réutilisé mais représente une seule transaction. Jusqu'à présent, j'ai mis en mémoire ainsi que des versions Linq-à-Sql du IUnitOfWork et ITable<T>.

Mon problème est que, en raison de l'injection de 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é. Comme il est la pièce principale qui est censé être connectable il se sent comme je l'ai 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 de travail (par exemple en mémoire, L2S, etc.).

Quel est le modèle le plus approprié pour cela? Je l'ai regardé

Était-ce utile?

Nous faire parvenir

La solution

Mise à jour: alors que cela n'a pas vraiment briser vers le bas, il a fini par produire juste un pauvre homme de IoC Container. J'ai fini juste de remplacer tous ces:

UnitOfWorkFactory.Create();

généralisé la mise en œuvre de services communs Locator:

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 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;
    }
}

D'où vient cette décomposer?

Answer 1

Mise à jour: alors que cela n'a pas vraiment briser vers le bas, il a fini par produire juste un pauvre homme de IoC Container. J'ai fini juste de remplacer tous ces:

UnitOfWorkFactory.Create();

généralisé la mise en œuvre de services communs Locator:

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 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;
    }
}

D'où vient cette décomposer?

Answer 2

Je suggère d'utiliser un modèle de Vistor pour découvrir les implémentations de l'interface IUnitOfWork.

[UnitOfWork(Name="foo")]
public class FooUnitOfWork : IUnitOfWork {}

Repository repo = new Repository("foo");
//stuff happens
repo.Save(); //or repo.Worker.Save();

A l'intérieur de l'instance repo une usine de découverte trouve le travailleur et crée.