Entity Framework 4 / POCO - od czego zacząć? [Zamknięte]

183

Programuję od jakiegoś czasu i wcześniej korzystałem z LINQ-To-SQL i LINQ-To-Entities (chociaż przy użyciu encji było to w relacji Entity / Table 1-1 - tj. Niewiele różni się od L2SQL)

Dużo czytałem o Inwersji Kontroli, Jednostce Pracy, POCO i wzorcach repozytoriów i chciałbym zastosować tę metodologię w moich nowych aplikacjach.

Walczę o znalezienie jasnego, zwięzłego przewodnika dla początkujących dla EF4, który nie zakłada znajomości EF1.

Konkretne pytania, na które muszę odpowiedzieć, to:

Pierwszy kod / pierwszy model? Plusy / minusy w odniesieniu do EF4 (tj. Co się stanie, jeśli najpierw zrobię kod, zmienię kod w późniejszym terminie i będę musiał ponownie wygenerować mój model DB - Czy dane są zachowywane i przekształcane lub usuwane?)

Zakładając, że idę najpierw po kod (chciałbym zobaczyć, jak EF4 konwertuje to do schematu DB) jak właściwie zacząć? Dość często widziałem artykuły ze schematami encji stwierdzającymi: „To jest mój model encji, teraz zamierzam ...” - Niestety nie jestem pewien, czy stworzyli model w projektancie, czy zapisali go w wygenerować kod, a następnie przerwać dalsze automatyczne generowanie kodu -lub- Oni mają zakodowane (POCO)? klasy i jakoś zaimportowały je do widoku deisgner?

Przypuszczam, że tak naprawdę potrzebuję zrozumienia, skąd pochodzi „magia” i jak ją dodać, jeśli nie generuję modelu EF bezpośrednio z bazy danych.

Wiem, że pytanie jest trochę niejasne, ale nie wiem, czego nie wiem - więc doceniam wszelkie uwagi / poprawki / wyjaśnienia.

Nie trzeba dodawać, że nie oczekuję, aby ktokolwiek tu siedział i uczył EF - chciałbym tylko kilka dobrych samouczków / forów / blogów / itp. dla kompletnych początkujących encji

Podstawowy
źródło
3
bądź naprawdę NAPRAWDĘ ostrożny, jeśli chodzi o żywotność twoich połączeń: bit.ly/fi83NV Jest to coś, o czym powinieneś naprawdę wiedzieć, kiedy wyodrębniasz konteksty do repozytoriów. Może się wydawać, że działa, ale tak naprawdę powoli rejestruje coraz więcej otwartych połączeń
BritishDeveloper
@BRitishDeveloper - Bardzo dobra rada. To nas złapało, ale w odwrotny sposób - używaliśmy kontenera IoC do pobierania repozytoriów i mieliśmy problem polegający na tym, że kontekst przypisany do repozytorium zamykał połączenie po pewnym czasie, ale nie został oznaczony jako usunięty / podobny. Ostatecznie sami rozszerzyliśmy kontekst o IsDisposed (), który sprawdzał zwykły stan usuwania i stan połączenia, pozwalając nam zbudować inny, jeśli to konieczne.
Podstawowy
Inną przydatną wskazówką jest to, że podczas uzyskiwania nowego kontekstu obiekty powiązane ze starym kontekstem nie będą miały odpowiedniego śledzenia zmian i spowodują problemy z niedopasowaniem kontekstu - więc jeśli masz długoterminową aplikację i zmieniasz kontekst w połowie, wykonanie, musisz ponownie pobrać wszystkie swoje podmioty. Aby było bardziej interesująco, musieliśmy mieć 2 biegające obok siebie czasami i skończyło się pisaniem kodu do mapowania między 2 ładnie ...
Podstawowy
1
@Basiclife Natknąłem się na ten sam problem :) Chciałem napisać swoje przemyślenia na temat aktualizacji odłączonych bytów i zachęciłeś mnie do tego: britishdeveloper.co.uk/2011/03/...
BritishDeveloper,

Odpowiedzi:

56

Artykuły te mogą być interesujące ... seria naprawdę ma zalety i wady podejścia POCO.

http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

http://blogs.msdn.com/b/adonet/archive/2009/05/28/poco-in-the-entity-framework-part-2-complex-types-deferred-loading-and-explicit-loading. aspx

http://blogs.msdn.com/b/adonet/archive/2009/06/10/poco-in-the-entity-framework-part-3-change-tracking-with-poco.aspx

W tych artykułach autor wymienia przyszłe artykuły opisujące najlepsze praktyki we wdrażaniu wzorców repozytorium i jednostki pracy, ale nie mogę ich znaleźć. Artykuły te są dobrze napisane i chciałbym przeczytać więcej od tego autora.

KellySandwiches
źródło
2
Dla kogoś, kto już zna się na Entity Framework korzystającym z projektanta, było to świetne wprowadzenie do POCO.
nathanchere
1
Jeśli szukasz kontynuacji jednostki pracy, znajduje się ona na blogs.msdn.com/b/adonet/archive/2009/06/16/...
Mike
7

Radzę zająć około pół godziny i wygenerować stabilny model EF1.0 w bieżącym VS. To da ci długą drogę do zrozumienia metafor i koncepcji EF 4.0. Po prostu przygotuj prostą bazę Klientów, Produktów i Zamówień ... Polecam robić własne i nie używać Northwind.

Chris B. Behrens
źródło
4

To świetne pytanie, ale trudne do aktualizacji, ponieważ Entity Framework nadal dojrzewa. Prawdopodobnie najlepszym miejscem na rozpoczęcie, które będzie aktualne w przyszłości, jest strona EF firmy Microsoft .

Kilka innych linków, które okazały się pomocne podczas googlingu (koncentruje się na Code First):

Dan
źródło
3

Możesz wziąć książkę Lermana lub coś prostszego, jak „Pro linq mapowanie obiektowo-relacyjne”. Wszystkie koncepcje są nadal takie same w POCO, z tym wyjątkiem, że teraz powinieneś wyłączyć generowanie kodu i mapować bezpośrednio na swój model w edmx csdl (lub utworzyć własny generator POCO). Wszystkie zasady mapowania są również takie same. W każdym razie w czasie wykonywania pracujesz z serwerem proxy, który pochodzi z obiektu POCO, więc powinieneś się martwić o obsługę przechwytywania (wirtualizacja właściwości POCO).

Głos
źródło
3

Istnieją również te samouczki:

Daniel
źródło
Jego struktura projektu wygląda jak stary projekt oparty na nHibernate, nad którym pracowałem. Z wyjątkiem jazzu WCF, na którym chętnie się odświeżam. Solidny link.
Merritt,
2

Oto przewodnik po szablonie POCO dla Entity Framework, który wyglądał całkiem nieźle. Możesz również zajrzeć na blog zespołu ADO.NET . Jeśli chcesz zacząć od początku (EF v1.0) jako podstawa twojej wiedzy o EF, znalazłem książkę Julii Lerman Programming Entity Framework bardzo kompletną.

DaveB
źródło
Dzięki - nie widziałem książki, ale przeczytałem oba podane linki. Przewodnik po szablonach jest przydatny w wyjaśnieniu, w jaki sposób można dodać dodatkową funkcjonalność do obiektów POCO po ich zdefiniowaniu (np. Leniwe ładowanie), ale (i może brakuje mi czegoś oczywistego tutaj) tak naprawdę nie wyjaśnia, jak zacząć (tj. Po prostu utworzenie określonej klasy nie czyni z niej bytu ani nie kojarzy go z modelem) Mam podobne doświadczenia z blogiem. Rozważę jednak zdobycie książki - wygląda obiecująco - dziękuję.
Podstawowy
2
Jeśli chodzi o książkę Julii Lerman, warto wspomnieć, że pracuje ona nad drugim wydaniem obejmującym EF4: learnentityframework.com/LearnEntityFramework/book/… . Pamiętam, że gdzieś przeczytałem, że planowana data publikacji jest w maju tego roku, ale nie mogę już znaleźć źródła. Również właśnie znalazłem tę stronę: nakedobjects.net/home/index2.shtml
Slauma
Slauma, podany przez ciebie link wyglądał dokładnie tak, jak potrzebuję - poza tym, że korzysta z zewnętrznej biblioteki „Naked Obects”, która wydaje się w jakiś sposób zaciemniać złożoność - Przez chwilę myślałam, że ją złamałeś
Basic
1

Julia Lerman ma niezłą serię filmów wprowadzających , około 10 minut każdy. Są wprowadzające, ale istnieje wiele praktycznych wskazówek, które usuwają potencjalne przeszkody w nauce. Szczególnie podobał mi się jej pokaz oglądania rzeczywistego SQL przy użyciu SQL Server Profiler.

David Pope
źródło
1

Jeśli zamierzasz korzystać z rozłączonych cenarios, polecam przeczytać książkę Julie Lerman: „Programowanie DbContext” w specjalnym rozdziale 4.

Znalazłem wiele przykładów na blogach itp., Ale prawie wszystkie dotyczą połączonych cenarios.

Ja też zaczynam. i ta książka bardzo mi pomogła. Nawiasem mówiąc, kupiłem jej trzy książki.

Rodolfo
źródło
0

Wow, wiele odpowiedzi. Co powiesz na przykład, który zawiera ulepszoną wersję szablonów T4, które generują POCO + interfejsy + repozytoria?

https://entityinterfacegenerator.codeplex.com

Uwierz2014
źródło
Interesujące i przydatne do testowania repozytoriów / kontekstów, ale dlaczego miałbyś chcieć abstrakować same byty? Z definicji nie powinny mieć w sobie żadnego kodu funkcjonalnego.
Podstawowy
Masz rację. Przeważnie ludzie nie będą musieli mieć oddzielnych interfejsów. Pomaga to jednak osobom, które chcą rozwiązywać cykliczne odwołania i chcą udostępniać interfejsy, a nie rzeczywiste klasy, stronie trzeciej. To bardzo pomoże, jeśli Twoja firma musi przejść audyt z integracją z podmiotem zewnętrznym, który nie wymaga szczegółowej implementacji w udostępnianiu.
Believe2014