La idea es crear una clase que expone un contexto pero maneja el almacenamiento de la misma en una aplicación web.Entity Framework: SingleConnect ObjectContext: bueno, malo o pensamiento oculto?
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 se ejecuta con una aplicación web, el contexto se crea en la primera necesidad (y se guarda en el HttpContext actual) y se destruye cada vez que se completa la solicitud.
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ás mínimo para no tener que hacer esto:
using(TISQLEntities context = new TISQLEntities())
{
....
}
Cada vez que desea consultar. Me doy cuenta de esto puede ser que yo sea perezoso, pero solo creo que es más fácil y más limpio que tener:
EntityContext.Context.User.Select(...)
y evita el "uso" que trato de evitar la mayoría de casos. Además de eso, no estoy creando contextos 9001 por devolución de datos.
Ahora, lo que me produce curiosidad es que estoy demasiado pensando en esto? ¿Debo seguir creando un contexto para cada método que lo necesite? Decir en un puesto de vuelta tengo que:
- conseguir que el usuario de un identificador de
- Obtener un sitio desde un id
- Añadir el Sitio al Usuario (user.Site = foundSite)
- Guardar el 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?
No sabía que esto era un patrón exactamente, pero sí que han trabajado con NHibernate antes y estaba tratando de hacer lo mismo con EF. Eso es básicamente lo que estoy tratando de lograr. –
Sí, hay algunos patrones de gestión de sesión. El patrón correcto más común es sesión por solicitud, sesión por conversación de negocios es muy nuevo, los antipatrones para administración de sesión son sesión por aplicación y sesión por llamada (sin administración, crear y destruir la sesión cada vez) –