asp.net - práctica - Marco de la entidad: ObjectContext único: ¿bueno, malo o pensamiento oculto?

entity framework tutorial español

Question

La idea es crear una clase que exponga un contexto pero maneje el almacenamiento de la misma en una aplicación web.

Actualmente esto es lo que tengo:

public class EntityContext
{

    private static String MAIN_CONTEXT_KEY = "MainContext";
    private static TISQLEntities _context;

    public static void RemoveContext()
    {
        if (
            HttpContext.Current != null 
            && 
            HttpContext.Current.Items[MAIN_CONTEXT_KEY] != null
           )
        {
            ((TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY]).Dispose();
            HttpContext.Current.Items[MAIN_CONTEXT_KEY] = null;
        }

        if (_context != null)
        {
            _context.Dispose();
            _context = null;
        }
    }

    public static TISQLEntities Context
    {
        get
        {
            if (HttpContext.Current == null)
            {
                if (_context == null)
                {
                    _context = new TISQLEntities();
                }

                return _context;
            }

            if (HttpContext.Current.Items[MAIN_CONTEXT_KEY] == null)
            {
                HttpContext.Current.Items[MAIN_CONTEXT_KEY] = new TISQLEntities();
            }

            return (TISQLEntities)HttpContext.Current.Items[MAIN_CONTEXT_KEY];
        }
    }
}

Y luego en el archivo Global.asax:

protected void Application_EndRequest(object sender, EventArgs e)
{
    EntityContext.RemoveContext();
}

La idea es que si esto se está ejecutando con una aplicación web, el contexto se crea en la primera necesidad (y se guarda en el HttpContext actual) y se anula cuando la solicitud termina.

Si esta es una situación UnitTest, es contra creada en la primera necesidad y eliminada en TestCleanup (No es tan importante en esta publicación, pero solo quería aclarar el objeto _context).

Ahora la idea detrás de esto es en lo mínimo no tener que hacer esto:

using(TISQLEntities context = new TISQLEntities())
{
  ....
}

Cada vez que quiero hacer una consulta. Me doy cuenta de que puede ser que yo sea flojo, pero creo que es más fácil y más limpio tener:

EntityContext.Context.User.Select(...)

Y evita el "uso" que trato de evitar en la mayoría de los casos. Además de eso, no estoy creando contextos 9001 por devolución de datos.

Ahora, lo que me produce curiosidad es que ¿estoy pensando en esto? ¿Debo seguir creando un contexto para cada método que lo necesite? Digamos en un mensaje de vuelta que tengo que:

• Obtener el usuario de una ID
• Obtener un sitio de una identificación
• Agregue el sitio al usuario (user.Site = foundSite)
• Salvar al usuario

Eso podría implicar al menos 3 contextos. ¿El marco de la entidad es lo suficientemente inteligente como para mantener la creación de contextos siempre?

Answer 1

Está implementando el equivalente de la sesión de NHibernate por patrón de solicitud, que es una buena construcción en NHibernate. Si bien no puedo decir con certeza al 100% que sea aplicable a EF, lo más probable es que sí. Una mayor expansión en otros patrones de administración de sesiones es la Sesión por Conversación Empresarial que permite a NHibernate extender la celebración de una sesión durante la duración de una HttpSesión desconectando y reconectando la sesión en lugar de destruirla y crearla. Si el EF permite una habilidad similar en lugar de mantener una conexión estática abierta, podrías ver cómo implementé ese patrón usando AOP en mi blog a través de mi perfil.

Answer 2

Si intenta implementar algo como lo hace NHibernate con su Session, creo que es una buena idea tener este tipo de patrón. Sé con certeza que en LinqToSql la implementación del objeto de contexto es más como una clase de punto de entrada que actúa como fachada. Me gustaría pensar que LinqToEntities es similar. Podría tener una implementación de fábrica para obtener un contexto de datos para su modelo en el que pueda reciclar el contexto de datos. Si va por el camino único, considere el cuello de botella, la disponibilidad y la responsabilidad del objeto singleton.

Answer 3

Consulte esta entrada de blog que proporciona más detalles sobre cómo crear un singleton para el contexto de Entity Framework y por qué esto no funcionaría en ASP.NET y se presenta una solución que hace algo similar a lo que sugiere.