Czytając jeden z ostatnich postów u Maćka zauważyłem, że w komentarzach pojawiła się krótka wymiana opinii na temat wyboru “właściwego” podejścia w kontekście korzystania z Entity Framework. Sam miałem okazję używać każdego z podejść oferowanych przez EF i z biegiem czasu zacząłem dostrzegać plusy i minusy poszczególnych podejść. W tym poście postanowiłem zebrać moje przemyślenia na ten temat.

Entity Framework oferuje trzy podejścia:

1. Code First – nie tworzymy schematu bazy wprost, zamiast tego definiujemy typy w C# odpowiadające modelowi danych, co w połączeniu z dodatkowymi adnotacjami i/lub Fluent API umożliwi EF wygenerowanie schematu bazy danych.
2. Database First – tworzymy model bazy danych samodzielnie, następnie importujemy istniejącą bazę do modelu, na podstawie którego EF wygeneruje potrzebne klasy i zajmie się mapowaniem.
3. Model First – tworzymy model bazy danych korzystając z designera, EF na podstawie gotowego modelu wygeneruje schemat bazy danych i odpowiadający mu zestaw klas.

Uważny czytelnik zauważy, że EF daje do dyspozycji trzy podejścia, a w tytule (świadomie) pominąłem jedno z nich- mianowicie Model First. Nie jest to pomyłka, ale świadomy zabieg, który wynika stąd, że mam do niego bardzo mieszane uczucia. Miałem okazję rozwijać projekty podążające tą drogą i zawsze podczas edycji modelu miałem wrażenie, że igram z szatanem i skończy się to płaczem, epitetami i siedzeniem po godzinach (a dlaczego, to może innym razem). Po takich doświadczeniach zwyczajnie nie zamierzam polecać go nikomu, biorąc pod uwagę, że EF oferuje dwie zadowalające alternatywy.

Podejście Code First

Z mojego punktu widzenia to podejście jest obecnie bardzo modne i ma powszechne zastosowanie w dużej liczbie projektów. Biorąc udział w pewnej liczbie projektów korzystających z tej metody udało mi się dojść do następujących wniosków:

Plusy

1.  Dzięki Code First programista nie musi wiedzieć jakie są różnice w semantyce języka DDL w zależności od wybranego silnika bazy danych. Wystarczy, że zdefiniuje odpowiednie struktury w C# a EF załatwia resztę.
2. Mamy do dyspozycji automatyczne migracje, co niesamowicie ułatwia aktualizowanie schematu bazy danych. Jesteśmy zwolnieni z pisania skryptów przyrostowych, migracje dbają o to za nas. Co więcej historia zmian jest automatycznie śledzona dzięki czemu bardzo szybko (i wygodnie) możemy cofnąć się do dowolnego stanu.
3. Nie mamy w projekcie olbrzymiego pliku XML z definicją wszystkich typów i mapowań. Zdecydowanie łatwiej jest mergować zmiany modelu, co w przypadku pracy w dużym zespole może mieć duże znaczenie, ponieważ jak napisał Andiego w jednym z komentarzy u Maćka:
   

    (…) praca z nim w dużym zespole przy dużym projekcie to wejście do 9 kręgu piekieł.

4. Jesteśmy uwolnieni od designera, który według mnie jest bardzo niewygodny (szczególnie przy pracy z dużymi bazami danych).
5. Kod C# modelu jest dużo bardziej czytelny niż w przypadku plików generowanych przez EF w pozostałych podejściach. Każdy, kto zaglądał do takich plików ten wie o czym piszę.

Minusy

1. Podejście Code First (przynajmniej na tą chwilę) nie wspiera mapowania funkcji. Jeżeli jest wysokie prawdopodobieństwo, że będziemy chcieli implementować funkcje po stronie bazy danych to w tym przypadku należy się zastanowić, czy jesteśmy w stanie zrezygnować z funkcji na rzecz procedur. Jeżeli nie, to lepiej wybrać skorzystać z podejścia Database First.
2. Korzystanie z procedur do modyfikacji danych insert/update/delete teoretycznie zostało wprowadzone do EF od wersji 6. W praktyce nie zawsze jesteśmy w stanie dopasować to rozwiązanie do naszych potrzeb. Problem tkwi w tym, że właściwości klasy muszą odpowiadać zarówno kolumnom w bazie danych i parametrom wejściowym procedur. Czasem może się zdarzyć, że będziemy trzymali w bazie puste kolumny tylko po to, żeby EF był w stanie ustawić odpowiednie mapowanie. Kolejnym ograniczeniem jest fakt, że nie można mieszać bezpośredniego dostępu do tabeli z odwoływaniem przez procedury. Albo wszystkie operacje odbywają się bezpośrednio albo przez procedury.
3. Używanie procedur w innym celu niż podany powyżej jest możliwe, ale wymaga zastosowania różnych obejść w zależności od scenariusza: Stored Procedures with Multiple Result Sets, Using Entity Framework Code First with Stored Procedures that have Output Parameters. Uważam to za duży minus dlatego, że programiści nie znający zbyt dobrze EF będą potrzebowali więcej czasu na zrozumienie zastosowanych rozwiązań.

 Podejście Database First

Miałem okazję rozwijać projekt oparty o to podejście i pracowało mi się całkiem dobrze. Pracowałem z tym podejściem dość długo i tutaj również doszedłem do pewnych wniosków:

Plusy

1. Baza danych może być projektowana przez osobę nie znającą EF. Taki scenariusz może mieć miejsce w projekcie, w którym bazę projektuje architekt baz danych. Zazwyczaj taka osoba nie będzie znała EF.
2. Odwrotnie niż w przypadku podejścia Code First tutaj mapowanie do funkcji, widoków i procedur jest wspierane i działa zadowalająco.
3. Łatwiej wdrożyć w projekt programistów nie znających EF.

Minusy

1. Czasem po zaktualizowaniu modelu nie zawsze wszystkie zmiany zostaną naniesione. Takie sytuacje niejednokrotnie mogą przyprawić o ból głowy osoby, które dopiero zaczynają przygodę z EF.
2. Mergowanie zmian w sytuacji, gdy dwie osoby dokonały modyfikacji bazy danych równolegle bardzo często jest problematyczne.
3. Nie mamy do dyspozycji migracji, samodzielnie musimy zarządzać aktualizacjami bazy danych.

Podsumowanie

Jak widać na postawione w tytule pytanie nie ma jednoznacznej odpowiedzi. Bardzo często spotykałem się z prostym podziałem: duża baza – Database First, mała – Code First. Według mnie rozmiar bazy danych nie ma żadnego znaczenia z punktu widzenia wyboru podejścia. Uważam, że przeważający wpływ ma specyfika samego schematu bazy danych. Każda z wybranych ścieżek ma plusy i szereg ograniczeń. Znając konsekwencje każdego z podejść zdecydowanie łatwiej podjąć trafną decyzję. Wybór jest o tyle istotny, że bardzo ciężko go zmienić w trakcie trwania projektu. Jasne, że dobre praktyki tworzenia kodu, odpowiednia abstrakcja i organizacja warstw powinny taką zmianę ułatwić, jednak w praktyce zmiana tak fundamentalnej decyzji może mieć rożne skutki i raczej jest niechętnie stosowana.

Zapraszam do dyskusji. Jestem przekonany, że temat nie został jeszcze wyczerpany.