Quale layer dovrei inserire .edmx e le classi POCO generate?

Question

Riguarda un design a strati con EF DB Primo modello.

Finora non ho utilizzato Entity Framework in precedenza, ho utilizzato solo Entità e inserito in un progetto diverso con sottocartelle Dominio/DTO. Riferito allo stesso modo in applicazioni DataAccessLayer, Business Layer e MVC e scritto un codice con le solite query ADO.Net e POCO preparati delle mie entità. Senza problemi.

Ora siamo sviluppo di un'applicazione utilizzando DB Entity Framework Primo modello. Abbiamo scelto questo modello DB First, poiché DB Design non è sotto il nostro controllo. È fatto da DBA.

Ho pensato di riutilizzare il vecchio design semplice qui. Ma non sono sicuro di dove/quale strato dovrei adattare esattamente il file edmx e le classi POCO generate. Non ho trovato alcun campione con uno stile di architettura a strati che utilizza l'approccio DBFirst.

Ho riferito questo. http://aspnetdesignpatterns.codeplex.com Ma usano NHybernate

Ecco la panoramica di alto livello del vecchio design.

Eventuali suggerimenti sul design/campioni, per favore siete i benvenuti.

Edit:

Dalla risposta qui sotto, penso che il quadro dell'entità produce il pocos potremmo rinominare entità esistenti/strato di dominio per strato del dominio e mettendo le classi POCO generate lì. Inoltre possiamo semplicemente mantenere .edmx in DataAccessLayer con l'elenco delle classi IRepository che include EF per TDD. Questo fa senso? o punti preziosi?

Aggiornamento:

Attualmente i rimosso DataAccessLayer e mantenere solo strato Entità che ha un file model.edmx e classi generate da EF e anche tutti classi Repository attuazione IRepository. Lo riferisco allo Business Layer, anche MVC. Sto facendo bene? Mi sento come sto facendo una cattiva progettazione :(Si prega di suggerire/Aiuto

Answer 1

A mio parere, Entity Framework utilizzato correttamente nega la necessità di un DAL separato. Penso a EF come il mio DAL. Esso consente di Concentrati sulla parte commerciale di più EF ti offre tutto il codice di accesso ai dati, puoi semplicemente utilizzare il tuo contesto EF nel tuo livello aziendale.Per me, questo è uno dei migliori vantaggi di EF, che è il tuo DAL

A seconda del modo in cui si separano i livelli (diversi assiemi o cartelle diverse all'interno di un assieme) dipende da dove vengono inserite le classi POCO. Se diversi assembly (che è eccessivo per la maggior parte dei progetti), un assembly "comune" a cui fanno riferimento tutti gli altri è posto a metti le lezioni di POCO. Se diverse cartelle, allora una cartella denominata "Modelli" o "DomainModels" è il luogo.

Specificamente per un'applicazione MVC, inserisco le mie classi POCO nella cartella "Modelli" (ho anche una cartella "ViewModels") e il mio .Edmx in una cartella BLL che talvolta chiamo "Logica".

Se è necessaria un'architettura liberamente accoppiata per il test, una cartella denominata Repository con il contesto EF avvolto nel proprio modello di repository è la strada da seguire.

Answer 2

DAL

• fal
• sal
• EF (qui si usa UnitOfWork sul repository generico (siccome si può cambiare e deve guardare i casi di prestazione))

BL (qui useresti IOC (Unity o Ninject) per isolare questo strato in base agli endpoint di utilizzo, come test ...)

• BL testabile DAL Gestore

MVC

• modello
• vista
• controllore

unittest (beffardo)

Credo che questo è il migliore m odel

Answer 3

Poiché si è sfortunatamente gravemente handicappati dalla decisione di creare il database per primo, sarà necessario utilizzare uno Anti-Corruption layer per Eric Evans' Domain-Driven Design.

Questa è una buona soluzione per cosa fare quando viene fornita un'interfaccia merda a cui è assolutamente necessario eseguire il codice: creare un'interfaccia attorno al DB che si comporti nel modo desiderato. Non esporre alcuna classe EF direttamente a qualcosa tranne il livello anti-corruzione stesso.

Ecco un esempio di lettura:

public class SomeReadService : ISomeReadService { 
    public SomeViewModel Load(Guid id) { 
    using (var dbContext = new DbContext()) { 
     // Query the DB model, then *map* the EF classes to SomeVieWModel. 
     // This way you are not exposing the shitty DB model to the outside world. 
    } 
    } 
} 

Ecco un esempio di scrittura:

public class SomeRepository : ISomeRepository { 
    public SomeDomainObject Load(Guid id) { 
    using (var dbContext = new DbContext()) { 
     // Map the EF classes to your domain object. Same idea as before. 
    } 
    } 
} 

vorrei ancora cercare di dimostrare al cliente che avere un design team separato DB sarà un disastro (e la mia esperienza indica con forza che lo farà). Vedi se c'è un modo in cui puoi fornire il feedback che dimostrerà al cliente che sarebbe meglio se tu progettassi il DB.

Answer 4

contesto Wrap nel vostro modello di pronti contro termine, e metterlo in una cartella denominata repository dove il BLL è ... sì, ma usarlo generica al tuo posto contesto (io non sono d'accordo con il modello in MVC) e risolvere con un contenitore nel BL perché la testabilità. Sì, hai ragione. EF deve essere DAL in condizioni normali. Il modello dovrebbe essere un altro livello integrato con tutti i progetti, ma potrebbe non essere limitato. Sì, l'esempio del wrapper che spiega il modello di repository generico, ma anche l'interfaccia IRepo deve essere dipendente da UnitOfWork (se necessario). E sei a posto se risolvi il tuo livello BL separato sul dominio. Penso QI = 180 :)

Answer 5

Si prega di consultare il link SO simile tipo di domanda di seguito:

With a database-first approach, how do I separate my Core and Infrastructure layers?

Spero che questo aiuti !!