Mylić o generatorach dla Entity Framework 4.1

Question

Oceniam Entity Framework dla projektu przeciwko starszej bazie danych. Baza danych jest dość dobrze zaprojektowana i już zdecydowano, że zastosujemy podejście Database-First. Aplikacja byłaby oparta na WinForm, ale chciałbym zaplanować z wyprzedzeniem i wziąć ASP.Net pod uwagę, a także być może zostanie poproszony przez kierownictwo w pewnym momencie i chciałbym ponownie użyć DAL.

Teraz rozumiem, że Entity Framework zapewnia kilka sposobów podmiot obiekty mają być generowane:

• Przedmioty pochodzące z EntityObject
• POCO (ObjectContext)
• POCO (DbContext)
• Jaźni -Tracking Entity (STE)

Próbowałem porównać trzy podejścia i mam już d tak daleko.

Szablon EntityObject T4 jest najbogatszym z nich wszystkich. Na przykład umieszcza komentarze z modelu encji w komentarzach XMLDoc na górze każdej klasy i każdej właściwości jednostki, która jest raczej przyjemna i użyteczna pod względem możliwości konserwacji kodu. Żaden z innych generatorów nie obsługuje tego po rozpakowaniu (chociaż rozumiem, że można modyfikować szablony T4, ale oczywiście wymaga to trochę pracy). Z drugiej strony, interfejs API DbContext jest nieco przyjemniejszy.

Typy pochodne EntityObject udostępniają zdarzenie, które można przechwycić, gdy zmienia się właściwość obiektu, co jest przydatne do implementacji logiki biznesowej.

Rozumiem, że POCO jest bardziej naturalne, ale generator T4 nadpisze wszystkie moje zmiany za każdym razem, gdy model ulegnie zmianie. Oczywiście, generowane POCO są klasami częściowymi, ale według mojej wiedzy nie można przesłonić właściwości już zdefiniowanej w częściowej klasie, więc nie jestem pewien, jak realizuje się w nich logikę biznesową?

Wiele osób wydaje się nienawidzieć klas pochodnych EntityObject, preferując podejście POCO, ale wydaje się, że tracę wiele przydatnych funkcji, które są dostarczane natychmiast po wprowadzeniu EntityObjects, przechodząc trasa POCO. Biorąc pod uwagę ogólną silną preferencję na obiektach POCO, mogę nie rozumieć czegoś, stąd moje pytanie.

Ostatni, który generator najlepiej pasuje do środowiska ASP.Net? Martwię się, że moje jednostki przestają być śledzone? Czy Self-Tracking Encje są bardziej przydatne w tym przypadku, czy też mają wartość tylko w usługach internetowych (których prawdopodobnie nie będę używał)?

Wielkie dzięki z góry.

Answer 1

Jeśli chcesz użyć EF 4.1, twoje opcje to tylko Generator DbContext. Wszystkie inne generatory (POCO, EntityObject i STE) są dla interfejsu ObejctContext API (EF 4.0). Opisałem różnice między generatorami here.

W twoim przypadku generator EntityObject może być użyty dla WinForm, ale będzie uciążliwy dla rozwiązania ASP.NET, gdzie POCO są lepsze, ponieważ aplikacja ASP.NET jest oddzielnym scenariuszem - będziesz musiał radzić sobie ze śledzeniem zmian w ASP.NET .

Celem STE jest opisane here, ale nie są one bardzo przydatne w WinForm, gdzie można użyć dołączonych podmiotów bezpośrednio lub ASP.NET gdzie demands to store them między żądaniami w widoku stanu.

Każda logika biznesowa, którą chcesz umieścić bezpośrednio w encji, musi być zakodowana w generatorze T4, w przeciwnym razie zostanie nadpisana po każdym pokoleniu. Każda funkcja z generatora bazującego na EntityObject, którą wspomniałeś, może być również zaimplementowana w generatorze POCO/DbContext.