EF6 (codice prima), MVC, Unity e un livello di servizio senza un repository
asp.net asp.net-mvc entity-framework entity-framework-6
Domanda
La mia applicazione utilizza SQL Server 2012, EF6, MVC e Web API.
Sta anche utilizzando un repository e file assortiti come:
DatabaseFactory.cs
Disposable.cs
IDatabaseFactory.cs
IRepository.cs
IUnitOfWork.cs
RepositoryBase.cs
UnitOfWork.cs
Utilizziamo già un livello di servizio tra i nostri controllori e il repository per alcune complicate logiche di business. Non abbiamo in programma MAI di passare a un altro database e mi è stato fatto notare che il pensiero recente è che EF6 è un repository quindi perché creare un altro repository su di esso e perché hanno tutti i file che ho sopra .
Sto iniziando a pensare che questo sia un approccio ragionevole.
Qualcuno sa di alcuni esempi là fuori che implementano EF6 senza un repository, con un livello di servizio . La mia ricerca sul web ha rivelato molti esempi di codice complessi che sembrano complicati senza alcuna ragione.
Il mio problema è anche quando si utilizza un livello di servizio, quindi dove metto:
context = new EFDbContext()
Nel controller, nel livello di servizio o in entrambi? Ho letto che posso farlo con un'iniezione di dipendenza. Uso già Unity come IOC ma non so come posso farlo.
Risposta popolare
Entity Framework È già un'implementazione del modello Unit of Work e un'implementazione generica del repository (DbContext è UoW e DbSet è il Repository generico). E sono d'accordo sul fatto che nella maggior parte delle app è eccessivo il modo di progettare un altro UoW o un Repository generico su di essi (inoltre, GenericRepsitory è considerato come un anti-pattern di alcuni).
Un livello di servizio può fungere da repository concreto, che presenta molti vantaggi dell'incapsulamento della logica dei dati che è specifico per le esigenze aziendali. Se si utilizza questo, non è necessario creare un repository su di esso (a meno che non si desideri modificare la tecnologia del servizio back-end, ad esempio da WCF a WebApi o altro).
Metterei tutti i tuoi dati di accesso nel tuo livello di servizio. Non fare l'accesso ai dati nel controller. Quello sta perdendo il tuo livello di dati nel tuo livello di interfaccia utente, e questo è solo un cattivo design. Violare molti dei concetti chiave SOLID.
Ma NON è necessario un UnitOfWork aggiuntivo o altri livelli oltre a quello nella maggior parte dei casi, a meno che le tue app siano molto complesse e pensate per funzionare in più ambienti ...
Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow