Czym są migracje EF Core i po co ich używać?
Migracje w EF Core to mechanizm śledzenia zmian w modelu danych aplikacji i automatycznego wprowadzania tych zmian do schematu bazy danych. Zamiast ręcznie pisać skrypty SQL do modyfikacji tabel czy kolumn, pozwalamy EF Core wygenerować pliki migracji opisujące te zmiany. Każda migracja reprezentuje jeden zestaw zmian (np. dodanie kolumny, utworzenie nowej tabeli, zmiana typu danych itp.), a EF Core dba o uporządkowanie i zastosowanie tych migracji we właściwej kolejności.
Kilka cech i korzyści migracji EF Core:
• Synchronizacja modelu i bazy: Za każdym razem, gdy zmieniasz klasy modeli (encje) w kodzie, możesz utworzyć migrację, aby utrzymać bazę danych w zgodzie z kodem. Dzięki temu unikamy sytuacji, w której aplikacja oczekuje np. kolumny, której nie ma w bazie danych.
• Przyrostowe zmiany: Migracje stosujemy kolejno, co pozwala zachować istniejące dane. EF Core porównuje bieżący model z migawką poprzedniego modelu (zapisaną w pliku snapshot) i na tej podstawie generuje potrzebne zmiany w nowej migracji. W bazie danych tworzona jest także specjalna tabela __EFMigrationsHistory, w której wersjonowane są zastosowane migracje – zawiera ona listę wszystkich migracji wraz z czasem ich zastosowania. To właśnie dzięki temu aplikacja wie, które migracje zostały już wykonane, a które jeszcze czekają na wdrożenie.
• Automatyzacja zamiast SQL: EF Core wygeneruje kod migracji (metody Up() i Down()), który dodaje lub usuwa odpowiednie obiekty bazy danych. Dzięki temu nie musisz pisać ręcznie skomplikowanych skryptów SQL, migracje zrobią to za Ciebie, co zmniejsza ryzyko błędów. Oczywiście zawsze warto przejrzeć wygenerowany kod migracji, szczególnie przy bardziej złożonych zmianach, i ewentualnie dostosować go do specyficznych potrzeb.
Tworzenie migracji krok po kroku
Przyjrzyjmy się teraz praktycznemu przebiegowi pracy z migracjami EF Core. Zakładam, że masz już utworzony model danych oraz skonfigurowany kontekst bazodanowy (DbContext).
Praca z migracjami zwykle wygląda następująco:
1. Wprowadzenie zmian w modelu: Najpierw dokonaj zmian w kodzie, np. dodaj nową klasę encji lub nową właściwość do istniejącej encji. Upewnij się, że aplikacja kompiluje się po tych zmianach.
2. Dodanie migracji: Użyj narzędzi EF Core, aby utworzyć migrację odzwierciedlającą zmiany.
Możesz to zrobić na dwa sposoby:
-W konsoli Package Manager Console w Visual Studio poleceniem:
Add-Migration InitialCreate
-W .NET CLI (np. w terminalu poza VS) poleceniem:
dotnet ef migrations add InitialCreate
gdzie InitialCreate (lub inna nazwa) to opisowa nazwa migracji, np. DodajTabeleUzytkownikow.
Dobrze jest nadawać migracjom opisowe nazwy, aby historia zmian była czytelna. Powyższe polecenie spowoduje wygenerowanie plików migracji w folderze (domyślnie o nazwie Migrations).
Wygenerowane zostaną m.in.:
-Plik migracji yyyyMMddHHmmss_InitialCreate.cs – zawierający metody Up() (logika wprowadzająca zmiany, np. tworzenie nowych tabel/kolumn) i Down() (logika cofająca te zmiany).
-Plik yyyyMMddHHmmss_InitialCreate.Designer.cs – zawiera metadane migracji potrzebne EF Core.
-Plik snapshot (np. NazwaKontekstuModelSnapshot.cs) – zawierający migawkę aktualnego modelu, służącą do porównywania przy generowaniu kolejnych migracji[7].
3. Zastosowanie migracji do bazy: Po dodaniu migracji czas zaktualizować bazę danych.
Wykonaj polecenie:
-W konsoli Menedżera Pakietów:
Update-Database
-W .NET CLI:
dotnet ef database update
Spowoduje to utworzenie lub zaktualizowanie fizycznej bazy danych zgodnie z definicjami w migracji. Przy pierwszej migracji EF Core utworzy bazę (jeśli jeszcze nie istnieje) oraz tabelę __EFMigrationsHistory, do której wpisze nazwę właśnie zastosowanej migracji. Kolejne migracje będą odpowiednio modyfikować schemat, np. dodawać kolumny, tworzyć nowe tabele i dopisywać się do wspomnianej tabeli historii migracji.
4. Weryfikacja: Sprawdź, czy wszystko poszło dobrze. Czy baza danych ma nowe/zmienione kolumny, tabele itp. Jeśli aplikacja korzysta z migracji automatycznie (np. wywołując context.Database.Migrate() przy starcie), uruchom aplikację i upewnij się, że nie zgłasza błędów związanych z bazą danych.
5. Powtarzanie procesu: Za każdym razem, gdy zmieniasz model, powtórz kroki 1–4, dodając nową migrację. Każda migracja dba tylko o różnicę względem poprzedniej, więc zmiany są przyrostowe i uporządkowane chronologicznie.
Wersjonowanie bazy danych w zespole
Praca z migracjami nabiera szczególnego znaczenia, gdy nad kodem pracuje zespół. Oto najlepsze praktyki, które pozwolą Wam uniknąć chaosu i konfliktów przy wspólnym wersjonowaniu bazy danych:
• Włącz migracje do kontroli wersji: Traktuj pliki migracji tak samo jak kod aplikacji, commituj je do repozytorium razem ze zmianami w modelu. Dzięki temu każdy członek zespołu, pobierając najnowszą wersję kodu, otrzymuje również najnowsze migracje. Repozytorium staje się źródłem prawdy o aktualnej strukturze bazy.
• Oddzielne bazy dla deweloperów: Nie dzielcie jednej wspólnej instancji bazy danych na etapie developmentu. Najlepiej, aby każdy programista miał swoją lokalną bazę danych (np. lokalną instancję SQL Server lub bazę plikową), na której będzie uruchamiał migracje. Dzięki temu praca jednej osoby (np. testowanie nowych migracji) nie wpływa na pracę innej, a ryzyko konfliktów się zmniejsza.
• Synchronizacja przed dodaniem migracji: W środowisku teamowym zdarza się, że dwie osoby jednocześnie pracują nad różnymi funkcjonalnościami, które wymagają zmian w bazie. Aby uniknąć konfliktów migracji, zanim dodasz nową migrację upewnij się, że masz zaktualizowany kod z repozytorium i zastosowane wszystkie migracje, które dodali inni (polecenie Update-Database po git pull). Dopiero na bazie aktualnego schematu twórz kolejną migrację. Taka praktyka zapobiega sytuacji, w której dwie migracje modyfikują ten sam fragment schematu i powodują konflikt przy łączeniu kodu.
• Rozwiązywanie konfliktów migracji: Jeśli zdarzy się, że po połączeniu gałęzi (branchy) wystąpi konflikt migracji, np. 2 migracje zostały utworzone równolegle i EF Core nie wie, którą zastosować najpierw - trzeba go rozwiązać podobnie jak konflikt w kodzie. Zwykle sprowadza się to do wycofania jednej z migracji lub utworzenia migracji łączącej (merge migration) tak, aby uporządkować sekwencję zmian. Ważne, by każdy deweloper miał identyczny zestaw migracji w tej samej kolejności. Narzędzia EF Core domyślnie dodają znacznik czasu do nazw plików migracji, co pomaga jednoznacznie ustalić ich kolejność chronologiczną. W przypadku konfliktu może być konieczne ręczne edytowanie migawki modelu lub skorzystanie z flagi -IgnoreChanges przy tworzeniu migracji, aby wygenerować "pustą" migrację synchronizującą stan modelu. Choć brzmi to skomplikowanie, w praktyce przy dobrej komunikacji w zespole takie sytuacje zdarzają się rzadko.
• Małe, częste zmiany: Starajcie się wprowadzać niewielkie, izolowane zmiany w bazie i tworzyć dla nich oddzielne migracje (np. jeśli dodajecie dwie niezależne kolumny lub indeksy, rozważcie dwie migracje zamiast jednej dużej). Mniejsze migracje są czytelniejsze, łatwiej je przetestować i ewentualnie wycofać bez wpływu na inne części systemu.
• Testowanie migracji: Pamiętajcie, by testować migracje przed wypuszczeniem zmian na środowisko wspólne (staging/produkcyjne). Najlepiej zastosować migracje na kopii bazy lub w bazie testowej, aby upewnić się, że przechodzą bez błędów i robią dokładnie to, czego oczekujecie. W środowisku produkcyjnym zaleca się ostrożność, niektórzy zamiast automatycznie uruchamiać Update-Database wolą wygenerować skrypt SQL (dotnet ef migrations script) i przejrzeć go przed zastosowaniem. Taki skrypt można też przekazać do wykonania administratorowi bazy danych.
• Nie pomijaj migracji: Unikaj sytuacji, w której ktoś wprowadza zmiany w schemacie bazy ręcznie, z pominięciem migracji. Jeśli trzeba coś zmienić bez EF Core (np. pilna poprawka na produkcji), upewnij się, że odpowiednia migracja odzwierciedlająca tę zmianę trafi później do kodu. W przeciwnym razie zespół utraci spójność. Baza jednego dewelopera może różnić się od bazy innego, a kolejne migracje mogą napotkać błędy (np. próba utworzenia tabeli, która już istnieje). Krótko mówiąc: migracje są źródłem prawdy dla struktury bazy i wszystkie zmiany powinny przez nie przechodzić.
Podsumowanie
Migracje EF Core to potężne narzędzie, które uporządkowuje proces zmian bazy danych. Dzięki nim baza nadąża za zmianami w kodzie, a cały zespół może pracować równolegle, nie bojąc się o niespodzianki przy integracji.
Kluczem jest włączenie migracji do codziennego workflow:
-każda zmiana w modelu - nowa migracja,
-migracje trafiają do repozytorium,
-po zaciągnięciu zmian - aktualizacja bazy.
W ten sposób Wasza baza danych będzie zawsze pod kontrolą, a wdrażanie nowych funkcjonalności stanie się szybsze i bezpieczniejsze.
Jeśli chcesz dowiedzieć się więcej o EF Core, nauczyć się optymalnie z niego korzystać oraz tworzyć szybkie zapytania do bazy w C#/.NET, rozważ dołączenie do mojego szkolenia online Szkoła Entity Framework Core. W tym szkoleniu krok po kroku omawiam pracę z EF Core (w tym migracje) i pokazuję dobre praktyki, które przydadzą się każdemu .NET Developerowi. Dzięki solidnej wiedzy narzędzia takie jak migracje staną się dla Ciebie codzienną pomocą w pracy, a nie źródłem problemów.
