Pytania z rozmów vol. 3 – .NET – EF Model First, DB First, Code First

Jednym z pytań, które zadawane jest na rozmowach kwalifikacyjnych jest to o Entity Framework i odpowiednim podejściu, które należy wybrać podczas tworzenia aplikacji. Spotkałem się już kilkukrotnie z podejściem, które kategorycznie odrzuca 2 z 3 dostępnych możliwości (nie zważając na warunki), zazwyczaj wybierając Code First lub DB First.

Code First – baza danych jest tworzona na podstawie wcześniej napisanych klas, zawierających zwykłe oraz nawigacyjne properties’y.

DB First – baza danych tworzona jest z poziomu np. SSMS (SQL Server Management Studio) przy użyciu SQL. Następnie model update’owany jest z poziomu .edmx, co z kolei powoduje update kodu w odpowiednich klasach lub ich wygenerowanie.

Model First – baza danych oraz odpowiednie klasy tworzone są na podstawie „wyklikiwania” w designerze.

Czy powinniśmy odrzucić jedno z podejść na początku naszych rozważań? Otóż niekoniecznie.

Najmniej lubianym wśród programistów jest podejście Model First. Jeżeli o mnie chodzi, to podzielam zdanie większości. Jednak w przypadku, gdy dysponujemy zespołem startujących w branży programistów, wydaje mi się, że jest to najłatwiejszy sposób pracy z aplikacją. Bardzo ciężko jest coś zepsuć, zazwyczaj kilka kliknięć pozwala na stworzenie poprawnego modelu. Niestety, wg mnie przy dużych projektach Model First nie sprawdza się. Edycja modelu, gdy mamy na nim kilkadziesiąt encji jest potwornie niewygodna, nie mówiąc już o relacjach pomiędzy nimi.

Jeżeli chodzi o DB First i Code First, różnica polega przede wszystkim na tym co zastaliśmy.

W przypadku, gdy mamy gotową bazę danych, dość naturalnym wyborem jest DB First. Należy jednak bardzo uważać, ponieważ wszelkie skrypty przyrostowe muszą być odpowiednio skonstruowane, żeby nie wywalić builda. Do tego po zaktualizowaniu pliku .edmx należy pamiętać o ręcznym usuwaniu właściwości, jeżeli takie usunięcie nastąpiło najpierw w bazie danych. Kolejnym punktem, na który należy zwrócić szczególną uwagę są relacje pomiędzy encjami – aktualizacja .edmx powoduje, że na modelu ustawiają się tzw. podwójne relacje – wyobraźmy sobie, że dysponujemy encją słownikową, np. StatusZamowienia oraz encją Zamowienia. Nie chcemy, aby pobierając z bazy danych wszystkie statusy zamówienia, automatycznie pobierały się wszystkie zamówienia, jakie istnieją w systemie. Niestety, po zaktualizowaniu modelu ustawi się właśnie taka relacja. Trzeba pamiętać, żeby usunąć ją z encji StatusZamowienia. W przypadku, gdy kilka osób pracuje jednocześnie na modelu, konieczne jest zwrócenie uwagi na to, czy skrypt z odpowiednim numerem nie istnieje już przed naszym „check-inem”. Jak widać, DB First wymaga pewnego doświadczenia u programistów, ponieważ bardzo łatwo jest coś zepsuć.

Code First, który osobiście bardzo lubię, jest świetnym wyborem, gdy tworzymy bazę danych od zera. Przede wszystkim wszelka interakcja z bazą danych następuje od strony kodu. Tworzymy klasy, dodajemy właściwości oraz właściwości nawigacyjne. Bazę update’ujemy za pomocą automatycznych migracji. Jest to najbardziej lubiane podejście w środowisku programistów.

Krótko podsumowując,

jeżeli chodzi o stopień trudności (od najtrudniejszego do najłatwiejszego):

1. DB First
2. Code First
3. Model First

jeżeli chodzi o wybór na podstawie dostępnych warunków:

DB First – istnieje baza danych, trzeba ją połączyć z aplikacją
Code First – tworzymy wszystko od zera
Model First – raczej niewielka aplikacja, mało doświadczony zespół

A co Wy o tym sądzicie?

9 uwag do wpisu “Pytania z rozmów vol. 3 – .NET – EF Model First, DB First, Code First

  1. Wypadałoby też dodać, że nazwa Code First może być cokolwiek myląca, bo wbrew pozorom to rozwiązanie da się stosować (z powodzeniem, choć w 100% zgadzam się, że żaden wariant nie jest automatycznie najlepszym rozwiązaniem), jeśli baza danych już istnieje. Podejście to pozwala nam wyeliminować warstwę pośrednią jaką jest model .edmx.

  2. Zaczalbym rozmowe od pytania jaki produkt buduje / rozwijam, potem zastanowilbym sie jakiej bazy danych uzyc by nastepnie zastanowic sie jakiego ORMa uzyc. To wg mnie byloby ciekawsze pytanie na rozmowie 🙂

    A co do sposobu uzywania ORM-a, Code First nawet jak istnieje juz baza danych.

    1. Co do Code First w momencie, gdy istnieje baza danych – jak najbardziej. Jednakże, najwygodniej jest wtedy stosować DB First 🙂 Przynajmniej w mojej opinii.

      1. Zdefiniuj wygodniej 😛 Chodzi raczej o brak .edmx’a ze wszystkimi wadami i zaletami; kod w końcu też można wygenerować automatycznie na podstawie bazy, do prostych rozwiązań działa bez zarzutów.

  3. Drobna uwaga co do statusu zamówienia i zamówień. W DBFirtst właściwości wynikające z relacji są wirtualne. EF nie zwraca typu który jest wygenerowany w Visualu tylko klasę proxy która zawiera np. Lazy loading referencji. Chroni to nas przed pobieraniem dużych obiektów z bazy może jednak powodować n+1 problem.

  4. Właśnie utknąłem na „Dużego Modelu” (mała betka dla niby dużego klienta, bardziej przypomina konfigurację). Modellerzy do mnie nie odzywają się, ogólnie odczuwam to ostatnie „odchrząknięcie”, co w Little Britain nazywa się „Computer says No”, dziesiątki-form na każdej czegoś innego designer, a w „międzyczasie” wirtualna lawina o nazwie Quality. Obecnie i docelowo rzeczywiście DB First. Weź tu bądź idealistą, gdy świat potrzebuje matematyków…

Zostaw komentarz

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Connecting to %s