EF, UoW e repository - Quando smaltire UnitOfWork in WebForms?

Question

Recentemente ho iniziato a scavare nel concetto di modelli di repository e UnitOfWork insieme ad esplorare EntityFramework.

fatto la mia propria implementazione sulla base di un esempio MVC, dove sono stati disporre l'UnitOfWork dal controller in questo modo:

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

Io non sono in MVC a tutti, e abbastanza nuovo in Webforms pure, ma presumo che stiano ignorando il metodo di disposizione del controller per disporre di UnitOfWork come "tutto" è disposto.

Fondamentalmente mi piacerebbe implementare lo stesso concetto nel mio sito Web ASP.NET WebForms e disporre di UnitOfWork che viene utilizzato dietro il codice di una Pagina insieme allo smaltimento della Pagina stessa.

ho pensato di aggiungere lo stesso alla Page_Unload evento dal ciclo di vita, ma non ero sicuro se questo è il modo corretto di farlo come non ho pasticciato con queste cose prima. La mia idea è la seguente:

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

Come posso farlo in modo sicuro e sono sulla buona strada?

Answer 1

Prima di tutto: non inventare la ruota.

Usa Dependency Injection quadri come: StructureMap, Ninject, Unità, ecc ....

tuo UoW dovrebbe essere avviato con inizio di una richiesta web e disposto quando il La richiesta termina.

In altre parole: DataContext di EF deve essere inizializzato quando viene avviata una richiesta. Quindi puoi salvarlo da qualche parte (Session, ...), e può essere riutilizzato per quella richiesta. Un'istanza di DataContext per richiesta.

Ma se si tenta di farlo da soli, si è nel modo sbagliato, utilizzando un framework di iniezione delle dipendenze, sarebbe così facile.

Il framework può gestire durata del DataContext (UoW).

Answer 2

Si dovrebbe dividere il software in strati e componenti ...

UI -> Controller -> Servizio -> DAL

Ad es

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(); 
    } 
} 

È anche possibile ricevere logica di query in metodi di servizio certiain esempio

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 
    } 
} 

Tuttavia, questo rende il test più complesso e richiede ai consumatori di servizi per capire i limiti e le migliori pratiche di LINQ to Entities.

anche io non consiglia di utilizzare la pura accademica Pattern Repository-per-base-tipo, come spesso efficiente consumare diversi tipi di dati dal stesso dominio richiedono incrociati query "repository" e richiedono join clausole tua LINQ o che il risultato di più query viene combinato e rimodellato prima di restituirlo come risultato pulito.

Trattate invece i vostri servizi come repository dominio-speicifc in cui è possibile ottenere vari tipi di output. In altre parole, usa SOA sotto il tuo MVC e sopra il tuo EF.