asp.net-mvc - framework - migrations asp net mvc

¿Cuál es la mejor manera de crear instancias y disponer de DbContext en MVC?

Question

MVC 3 + EF 4.1

Estoy eligiendo entre dos enfoques para tratar con DbContext:

1. Cree una instancia en Application_BeginRequest , póngalo en HttpContext.Current.Items y disponga en Application_EndRequest .
2. Cree UnitOfWork desechable (kindof wrapper para DbContext ) y comience cada acción del controlador con using(var unitOfWork = new UnitOfWork()) { ... }

Comparte tu experiencia por favor: ¿Cuál preferirías? ¿Cuáles son los pros y los contras de cada enfoque?

Answer 1

Actualmente utilizamos repositorios inyectados con UoW (unidad de trabajo) instanciados a través del localizador de servicios desde una fábrica de repositorios. La unidad controla la vida de esta manera, alejando el trabajo de ti.

Su implementación particular variará dependiendo de si usa POCO, objetos de entidad, etc.

En última instancia, desea UoW si va a trabajar con más de un conjunto de objetos en su controlador para garantizar que solo use un contexto. Esto mantendrá sus transacciones bajo control, etc.

Si vas a utilizar múltiples objetos-contextos (es decir, múltiples EDMX), querrás consultar el uso de UoW con MSDTC ... pero probablemente sea más de lo que querías saber. Al final, lo importante es asegurarse de que solo crea una instancia de lo que necesita para la acción del controlador (es decir, una instancia del contexto). No creo que vaya con Begin_Request, es posible que ni siquiera necesite el contexto para cada solicitud.

Answer 2

Le sugiero que utilice un marco de inyección de dependencia. Puede registrar su DbContext según solicitud

 container.RegisterType<MyDbContext>().InstancePerHttpRequest();

E inyéctelo como un parámetro constructor para el controlador.

public class MyController : Controller
{
public MyController(MyDbContext myDbContext)
{
_myDbContext = myDbContext;
}
}

Si el tipo registrado implementa IDisposable , el marco DI lo eliminará cuando finalice la solicitud.

Primer enfoque: es mucho más limpio usar el marco de ID que implementarlo manualmente. Además todas sus solicitudes pueden no necesitar su UoW.

Segundo enfoque: El controlador no debe saber cómo construir su UoW (DbContext). El propósito no es reducir el acoplamiento entre componentes.

Answer 3

No ponga DbContext en global.asax! :

1. ¿Campo estático de DbContext en Global.asax frente al campo de instancia de DbContext en la clase de controlador?
2. Contexto del marco de la entidad como estático