Entity Framework Contexte Singleton

Je suis en train de construire une Application qui utilisent Contexte de l'EF dans le Pattern Singleton comme NHibernate de travail de la Session:

public class DbContextFactory
{
    private static volatile DbContextFactory _dbContextFactory;
    private static readonly object SyncRoot = new Object();
    public DbContext Context;

    public static DbContextFactory Instance
    {
        get
        {
            if (_dbContextFactory == null)
            {
                lock (SyncRoot)
                {
                    if (_dbContextFactory == null)
                        _dbContextFactory = new DbContextFactory();
                }
            }
            return _dbContextFactory;
        }
    }

    public DbContext GetOrCreateContext()
    {
        if (this.Context == null)
            this.Context = new DbContext(ConfigurationManager.AppSettings["DefaultConnectionString"]);

        return Context;
    }
}

Je suis en utilisant Ninject pour Injecter le Contexte:

public class DbContextModule : NinjectModule
{
    public override void Load()
    {
        Bind<IDbContext>().ToConstant(DbContextFactory.Instance.GetOrCreateContext());
    }
}

Je suis en train de lire à propos de cette approche, et certaines personnes disent que c'est une mauvaise pratique et je vais avoir des problèmes.

Quelqu'un qui sait à ce sujet avec EF peut m'expliquer plus en détails?

Avez-vous lire c'est une mauvaise pratique? Sans explication?

OriginalL'auteur Acaz Souza | 2011-09-21

  1. 3

    NHibernate n'utilisez pas de Session en tant que singleton ... un Tel scénario n'a qu'un sens dans de très rares cas où votre candidature est très courte lot représentant unique de la transaction ou de l'unité de travail.

    Ici sont décrits les raisons pourquoi vous ne devriez pas utiliser le /long de la vie. En cas de multithread ou d'une application serveur de servir plusieurs clients, vous ne devez pas utiliser contexte partagé.

    Ce Singleton dans NHibernate? La SessionFactory?
    Regarde mon approche, existe aucun problème? Je peux dire à Ninject utiliser dans un RequestScope.
    Oui, l'usine peut être utilisé comme un singleton et de créer une nouvelle Session chaque fois que cela est nécessaire. Demande portée est normalement utilisée pour le contexte de l'application web scénarios.
    Je suis confus, regarde mon approche, je suis à la résolution du problème posé InRequestScope dans Ninject de Configuration?
    Je ne vois pas de demande de la portée de votre code et toujours à l'aide de votre singleton usine à la demande de la portée va pas le résoudre, parce qu'il reviendra de la même instance de contexte à chaque fois.

    OriginalL'auteur Ladislav Mrnka

  2. 0

    Une bonne pratique est d'utiliser un datacontext par unité de travail
    Pour avoir plus d'informations sur l'unité de travail avec EF, vous devriez lire http://blogs.msdn.com/b/adonet/archive/2009/06/16/using-repository-and-unit-of-work-patterns-with-entity-framework-4-0.aspx

    Quand on partage la même datacontext vous êtes probablement en train de sauvegarder un peu de 10s de millisecondes. Le mot de micro-optimisation des ressorts à l'esprit - dans ce cas, vous ne devriez probablement pas être en utilisant Entity Framework.

    Avoir un DataContext qui n'est jamais fermée vous permet de lazy load quand vous le souhaitez. Vous avez laissé votre Service et maintenant dans votre Contrôleur ou pire encore, votre point de Vue. Accès à la base de données à partir d'une Vue de demande pour les problèmes de performances comme je suis sûr que vous n'avez pas intentionnellement. Il est plus probable parce que vous avez oublié avides de charger toutes les données dont vous avez besoin pour remplir votre point de vue.

    L'Article n'est plus disponible.

    OriginalL'auteur meziantou

  3. 0

    De lire cet article.
    Pourquoi vous ne devriez pas utiliser singleton DataContexts dans le Cadre de l'Entité?
    http://www.britishdeveloper.co.uk/2011/03/dont-use-singleton-datacontexts-entity.html

    S'il vous plaît ajouter les parties pertinentes de l'article pour votre réponse. De cette façon, si le lien ne parvient pas votre réponse sera toujours un sens.

    OriginalL'auteur Marcos

  4. 0
    public class Dock
{
    //Statik field
    private static Dock _dock;
    //lock object
    private static object lockObject = new object();

    //We prevent the constructive method from being modeled with new by 
    //making it secret.
    private Dock()
    {

    }
    //Class in Instance
    public static Dock Instance()
    {   
        if (_dock == null)
        {
            lock (lockObject)
            {
                if (_dock == null)
                    _dock = new Dock();
            }
        }
        return _dock;
    }

    }

    OriginalL'auteur Tugay ÜNER