EF, UoW y repositorio: ¿cuándo disponer el UnitOfWork en WebForms?

Question

Recientemente comencé a profundizar en el concepto de Repository Patterns y UnitOfWork junto con la exploración de EntityFramework.

hizo que mi propia aplicación basada en un ejemplo MVC, donde fueron disponer el UnitOfWork desde el controlador de esta manera:

protected override void Dispose(bool disposing) 
{ 
    unitOfWork.Dispose(); 
    base.Dispose(disposing); 
} 

No estoy en MVC en absoluto, y bastante nuevo en formularios web, así, pero supongo que están anulando el método de disposición del controlador para disponer el UnitOfWork ya que "todo" está dispuesto.

Básicamente me gustaría implementar el mismo concepto en mi sitio web ASP.NET WebForms y deshacerme del UnitOfWork que se utiliza detrás del código de una página junto con la eliminación de la página en sí.

Consideré agregar lo mismo al Página_Unload evento del ciclo de vida, pero no estaba seguro de si esta es la manera correcta de hacerlo, ya que no me he equivocado con tales cosas antes. Mi idea de la siguiente manera:

protected void Page_Unload(object sender, EventArgs e) 
{ 
    unitOfWork.Dispose(); 
    base.Dispose(); 
} 

¿Cómo puedo lograr que con seguridad, y estoy en el camino correcto?

Answer 1

Antes que nada: no invente la rueda.

Uso inyección de dependencias marcos como: StructureMap, Ninject, Unidad, etc ....

Su UoW debe iniciarse con una petición de principio web y dispuestos cuando el solicitud ha finalizado.

En otras palabras,: DataContext of EF debe inicializarse cuando se inicia una solicitud. Luego puede almacenarlo en alguna parte (Session, ...) y puede reutilizarse para esa solicitud. Una instancia de DataContext por solicitud.

Pero si intenta hacerlo usted mismo, está en el camino equivocado, utilizando un marco de inyección de dependencias, lo haría tan fácil.

El marco puede manejar vida de su DataContext (UoW).

Answer 2

Usted debe dividir su software en capas y componentes ...

interfaz de usuario -> Controlador -> Servicio -> DAL

P. ej

UI.Submit -> Controller.SaveUserInfo -> UsersManagementService.SaveUserInfo ->

public void SaveUserInfo(User user) 
{ 
    using (var uow = new Uow()) 
    { 
     var dbUser = uow.Users.GetByKey(user.Id); 
     if (dbUser == null) 
     { 
      // TODO: 
     } 

     dbUser.Name = user.Name; 
     dbUser.Address = user.Address; 
     // Or use a framework for injecting properties 

     uow.SaveAndAcceptChanges(); 
    } 
} 

Puede incluso recibir lógica de consulta en los métodos de servicio, por ejemplo certiain

public User GetUsersMatching(Func<IQueryable<User>, IQueryable<User>> query) 
{ 
    using (var uow = new Uow()) 
    { 
     var users = query(uow.Users).ToList(); 
     return users; 

     // For this to work using POCOs you may need to disable proxy creation 
    } 
} 

Sin embargo, esto hace que la prueba más compleja y requiere que los consumidores de servicio a entender las limitaciones y las mejores prácticas de LINQ a Entidades.

También se recomienda utilizar el patrón puramente académica repositorio-per-tipo base, tan a menudo a eficiente consumir diferentes tipos de datos de el mismo dominio requieren transversales consultas "depósito" y requieren join cláusulas en su LINQ o que el resultado de múltiples consultas se combinan y se modifican antes de devolverlo como un resultado limpio.

En lugar de tratar sus servicios como dominio-speicifc-repositories donde puede obtener varios tipos de resultados. O en otras palabras, use SOA bajo su MVC y por encima de su EF.