W której warstwie powinienem umieścić .edmx i wygenerować klasy POCO?

Question

Dotyczy to warstwowej konstrukcji z pierwszym modelem EF DB.

Do tej pory nie korzystałem wcześniej z Entity Framework, wykorzystałem tylko Encje i umieściłem je w innym projekcie z podkatalogami Domain/DTO. Odwołano to samo w aplikacji DataAccessLayer, Business Layer i MVC i napisałem kod ze zwykłymi zapytaniami ADO.Net i przygotowałem POCO moich jednostek. Nie ma problemów.

Teraz jesteśmy rozwijanie aplikacji przy użyciu Entity Framework DB Pierwszy model. Wybraliśmy ten model DB First, ponieważ DB Design nie jest pod naszą kontrolą. Robi to DBA.

Myślałem o ponownym użyciu starego prostego wzoru tutaj. Ale nie wiem, gdzie/która warstwa powinien dokładnie pasować do pliku edmx i wygenerowanych klas POCO. Nie znalazłem żadnych próbek z warstwowym stylem architektury opartym na podejściu DBFirst.

Odesłałem to. http://aspnetdesignpatterns.codeplex.com Ale oni używają NHybernate

Oto ogólny przegląd starego projektu.

Wszelkie sugestie dotyczące projektu/próbek, proszę przyjąć.

Edit:

z poniższej odpowiedź, myślę, że ramy podmiot produkuje Poços moglibyśmy zmienić nazwę istniejących podmiotów/warstwa domenę do warstwy domeny i oddanie wygenerowanych klas POCO tam. Możemy również po prostu zachować .edmx w DataAccessLayer z listą klas IRepository, które otaczają EF dla TDD. Czy to ma sens? lub jakiekolwiek cenne punkty?

Aktualizacja:

Obecnie usunąłem DataAccessLayer i zachować tylko podmioty warstwę, która ma plik model.edmx i klas generowanych przez EF a także wszystkie klas repozytorium za wykonawczych IRepository. Odnoszę to również do Business Layer, MVC. Czy robię dobrze? Czuję, że robię złą konstrukcję :(Proszę zaproponować/pomoc

Answer 1

Moim zdaniem, Entity Framework stosowane prawidłowo neguje potrzebę DAL oddzielne. Myślę EF jako mojego DAL. To pozwala na Skoncentruj się na części biznesowej więcej EF tworzy dla Ciebie cały kod dostępu do danych, możesz po prostu użyć kontekstu EF w twojej warstwie biznesowej, dla mnie jest to jedna z najlepszych korzyści EF, że jest to twój DAL

W zależności od sposobu oddzielania warstw (różne złożenia lub różne foldery w zespole) zależy od tego, gdzie umieścić swoje klasy POCO.Jeśli różne zestawy (co jest przesadą dla większości projektów), to "wspólny" zespół, do którego odwołują się wszystkie inne, to miejsce na ułożyć klasy POCO. Jeśli są to różne foldery, miejscem jest folder o nazwie "Modele" lub "Modele domen".

W szczególności dla aplikacji MVC, umieściłbym moje klasy POCO w folderze "Modele" (mam również folder "ViewModels") i mój plik .Edmx w folderze BLL, który czasami nazywam "Logic".

Jeśli potrzebna jest luźno powiązana architektura do testowania, należy przejść do folderu o nazwie Repositories z kontekstem EF owiniętym we własny wzór repozytorium.

Answer 2

DAL

• fal
• sal
• EF (tutaj należałoby użyć UnitOfWork na rodzajowy repozytorium (poniewaz może to zmienić i musi wyglądać przypadki wydajności))

BL (tutaj używałbyś IOC (Unity lub Ninject) do izolacji tej warstwy zgodnie z punktami końcowymi użycia, jak testowanie ...)

• BL sprawdzalne DAL Menedżer

MVC

• modelu
• widok
• kontroler

unittest (szyderczy)

myślę, że to jest najlepszy m Odel

Answer 3

Ponieważ niestety ciężko upośledzona decyzja o utworzeniu bazy danych jako pierwszej, musisz użyć Anti-Corruption layer na Eric Evans' Domain-Driven Design.

Jest to dobre rozwiązanie, jeśli chodzi o to, co należy zrobić, gdy dostajesz gówniany interfejs, na który absolutnie musisz się przekodować - utwórz interfejs owinięty wokół DB, który zachowuje się tak, jak chcesz. Nie wolno wystawiać żadnych klas EF bezpośrednio na nic poza samą warstwą antykorupcyjną.

Oto czytanie przykład:

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

Oto pisanie przykład:

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

chciałbym jeszcze spróbować udowodnić klientowi, że ma oddzielny projekt zespołu DB będzie katastrofy (a moje doświadczenie wyraźnie wskazuje, że tak się stanie). Sprawdź, czy istnieje sposób dostarczenia informacji zwrotnych, które pokażą klientowi, że byłoby lepiej, gdybyś zaprojektował DB.

Answer 4

kontekst Wrap w swojej strukturze repo, i umieścić go w folderze o nazwie repozytoriów gdzie BLL jest ... tak, ale używać go rodzajowy w miejscu kontekstowego (ja dont zgodzić się z modelu w MVC) i rozwiązać z pojemnik w BL, ponieważ jest podatny na tesability. Tak, masz rację EF musi być DAL w normie. Model powinien być inną warstwą zintegrowaną ze wszystkimi projektami, ale może nie być poco. Tak, Twój przykład otoki tłumaczący ogólny wzór repozytorium, ale musi też istnieć interfejs IRepo zależny od UnitOfWork (jeśli potrzebujesz). I jesteś na dobrej drodze, jeśli rozwiążesz oddzielną warstwę BL w domenie. myślę IQ = 180 :)

Answer 5

proszę zobaczyć link więc dla podobnego rodzaju pytanie poniżej:

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

nadzieję, że pomoże !!