c#, entity framework: utilisation correcte de la classe DBContext à l'intérieur de votre référentiel de la classe

Supposons, vous avez plus d'un dépôt et que vous devez mettre à jour 2 enregistrements à partir des référentiels différents. Et vous devez le faire transactionnelle (si l'on omet - les deux mises à jour restaurations):

var repositoryA = GetRepository<ClassA>();
var repositoryB = GetRepository<ClassB>();

repository.Update(entityA);
repository.Update(entityB);

Donc, si vous avez propre DbContext pour chaque référentiel (cas 2), vous devez utiliser TransactionScope pour atteindre cet objectif.

De mieux - ont partagé DbContext pour une opération (pour un simple appel, pour un unité de travail). Donc, DbContext pouvez gérer la transaction. EF est assez pour que.
Vous pouvez créer un seul DbContext, faire toutes les modifications dans de nombreux référentiels, appelez SaveChanges une fois, mettez-la au rebut après toutes les opérations et le travail est fait.

Ici est un exemple de UnitOfWork modèle de mise en œuvre.

Votre deuxième voie peut être bon pour les opérations en lecture seule.

De l'approche à utiliser dépend de la responsabilité du référentiel.

Est de la responsabilité du référentiel pour effectuer des transactions? c'est à dire d'apporter des modifications, puis enregistrer les modifications apportées à la base de données en appelant `SaveChanges? Ou est-ce seulement une partie d'une plus grande transaction et, par conséquent, il ne apporter des modifications sans les enregistrer?

Cas n ° 1) Le dépôt d'exécuter des transactions (il faudra effectuer les modifications et les enregistrer):

Dans ce cas, la seconde approche est le meilleur (l'approche de votre deuxième exemple de code).

Je ne modifier cette approche légèrement par l'introduction d'une usine comme ceci:

public interface IFactory<T>
{
    T Create();
}

public class Repository : IRepository
{
    private IFactory<MyContext> m_Factory;

    public Repository(IFactory<MyContext> factory)
    {
        m_Factory = factory;
    }

    public void AddCustomer(Customer customer)
    {
        using (var context = m_Factory.Create())
        {
            context.Customers.Add(customer);
            context.SaveChanges();
        }            
    }
}

Je suis en train de faire cette petite modification pour permettre L'Injection De Dépendance. Cela nous permet de modifier ultérieurement la façon dont nous créons le contexte.

Je ne veux pas le référentiel d'avoir la responsabilité de créer le contexte lui-même. L'usine, qui met en œuvre IFactory<MyContext> aura la responsabilité de créer le contexte.

Remarquez comment le référentiel est la gestion de la durée de vie du contexte, il crée le contexte, ne fait quelques modifications, enregistrez les modifications, puis cède le contexte. Le référentiel a une durée de vie plus longue que le contexte dans ce cas.

Cas #2) Le référentiel est partie d'une grande opération (il va faire quelques changements, d'autres référentiels de faire d'autres changements, et puis quelqu'un d'autre va valider la transaction en invoquant SaveChanges):

Dans ce cas, la première approche (que vous décrivez d'abord dans votre question), c'est mieux.

Imaginer ce que cela va à comprendre comment l'espace de stockage peut être une partie d'une plus grande transaction:

using(MyContext context = new MyContext ())
{
    repository1 = new Repository1(context);
    repository1.DoSomething(); //Modify something without saving changes
    repository2 = new Repository2(context);
    repository2.DoSomething(); //Modify something without saving changes

    context.SaveChanges();
}

Veuillez noter qu'une nouvelle instance du référentiel est utilisé pour chaque transaction. Cela signifie que la durée de vie du référentiel est très court.

Veuillez noter que je suis en nouvelle-ing le référentiel dans mon code (qui est une violation de l'injection de dépendance). Je suis juste montrer un exemple. Dans le code réel, nous pouvons utiliser les usines de résoudre ce problème.

Maintenant, l'une des améliorations que nous pouvons faire de cette approche est de cacher le contexte derrière une interface afin que le référentiel n'a plus accès à SaveChanges (jetez un oeil à la L'Interface De La Ségrégation Principe).

Vous pouvez avoir quelque chose comme ceci:

public interface IDatabaseContext
{
    IDbSet<Customer> Customers { get; }
}

public class MyContext : DbContext, IDatabaseContext
{
    public IDbSet<Customer> Customers { get; set; }
}


public class Repository : IRepository
{
    private IDatabaseContext m_Context;

    public Repository(IDatabaseContext context)
    {
        m_Context = context;
    }

    public void AddCustomer(Customer customer)
    {
        m_Context.Customers.Add(customer);      
    }
}

Vous pouvez ajouter d'autres méthodes que vous avez besoin de l'interface si vous le souhaitez.

Veuillez noter également que cette interface n'hérite pas de IDisposable. Ce qui signifie que le Repository classe n'est pas responsable de la gestion de la durée de vie du contexte. Le contexte, dans ce cas, une plus grande durée de vie que le référentiel. Quelqu'un d'autre s'occupera de la gestion de la durée de vie du contexte.

Notes sur le premier article:

Le premier article suggère que vous ne devriez pas utiliser la première méthode que vous décrivez dans votre question (injecter le contexte dans le référentiel).

L'article n'est pas clair sur la façon dont le référentiel est utilisé. Il est utilisé comme une partie d'une seule opération? Ou faut-il s'étendre sur plusieurs transactions?

Je suppose (je ne suis pas sûr), que dans l'approche que l'article est de décrire (négativement), le référentiel est utilisé comme une mesure d'exécuter le service qui va s'étaler sur un grand nombre de transactions. Dans ce cas je suis d'accord avec l'article.

Mais ce que je suggère ici, c'est différent, je suggère que cette approche est utilisée uniquement dans le cas où la création d'une nouvelle instance du référentiel est créé chaque fois qu'une opération est nécessaire.

Notes sur le deuxième article:

Je pense que ce que le deuxième article est d'en parler est pas pertinent pour quelle approche vous devriez utiliser.

Le second article, il est question de savoir s'il est nécessaire de disposer du contexte, dans tous les cas (pas pertinent pour la conception du référentiel).

Veuillez noter que dans les deux approches de conception, nous sommes à l'aliénation du contexte. La seule différence, c'est qui est responsable de cette disposition.

L'article est de dire que le DbContext semblent propres ressources, sans la nécessité de disposer du contexte explicitement.

Le 1er code n'a pas rapport à la scability problème, la raison pour laquelle elle est mauvaise, c'est parce qu'il créer un nouveau contexte pour chaque référentiel qui est mauvais, qui l'un des commentateurs de commentaires, mais il n'a pas encore de réponse. Dans le web, il a été 1 demande 1 dbContext, si vous prévoyez d'utiliser un modèle de référentiel, puis il se traduire en 1 demande > beaucoup de référentiel > 1 dbContext. ce facile à réaliser avec du Cio, mais pas nécessaire. c'est la façon dont vous le faites sans Cio:

var dbContext = new DBContext(); 
var repository = new UserRepository(dbContext); 
var repository2 = new ProductRepository(dbContext);
//do something with repo

Que pour l'élimination ou pas, j'ai l'habitude de jeter, mais si la conduire lui-même a dit cela, alors probablement aucune raison de le faire. Je voudrais juste jeter si il a IDisposable.

J'utilise la première méthode (l'injection de la dbContext) bien sûr, il devrait être un IMyDbContext et votre dépendance à l'injection du moteur, c'est de gérer le cycle de vie du contexte, de sorte que c'est seulement de vivre, alors qu'il est nécessaire.

Cela vous permet de vous moquer du contexte pour les tests, le deuxième moyen le fait qu'il est impossible d'examiner les entités sans une base de données pour le contexte d'utilisation.

Je pense que cette première approche est la meilleure, vous n'aurez jamais à créer un dbcontext pour chaque référentiel, même si vous disposer.
Cependant, dans le premier cas, vous pouvez utiliser un databaseFactory pour instancier un seul dbcontext:

 public class DatabaseFactory : Disposable, IDatabaseFactory {
    private XXDbContext dataContext;

    public ISefeViewerDbContext Get() {
        return dataContext ?? (dataContext = new XXDbContext());
    }

    protected override void DisposeCore() {
        if (dataContext != null) {
            dataContext.Dispose();
        }
    }
}

Et d'utiliser cette instance dans le Référentiel:

public class Repository<TEntity> : IRepository<TEntity> where TEntity : class
{
    private IXXDbContext dataContext;

    private readonly DbSet<TEntity> dbset;

    public Repository(IDatabaseFactory databaseFactory) {
        if (databaseFactory == null) {
            throw new ArgumentNullException("databaseFactory", "argument is null");
        }
        DatabaseFactory = databaseFactory;
        dbset = DataContext.Set<TEntity>();
    }

    public ISefeViewerDbContext DataContext {
        get { return (dataContext ?? (dataContext = DatabaseFactory.Get()));
    }

    public virtual TEntity GetById(Guid id){
        return dbset.Find(id);
    }
....