ThinkingInCode

<h2>Czym są migracje w Entity Framework?</h2> Podczas gdy piszemy w ORM’ie takim jak EF, często chcemy modyfikować strukturę bazy, nawet jeżeli przechowujemy już w niej jakieś dane. EF do tego celu udostępnia tzw. migracje. Są to aktualizacje struktury bazy, mające miejsce po wprowadzeniu zmian w klasach modelu, dzięki którym nie zawsze tracimy dane przechowywane w bazie. <h2>Czy to znaczy, że korzystając z migracji nigdy nie tracimy danych?</h2> Chciałoby się rzec: Bez przesady! :). Migracje dzielą się na stratne i bezstratne. Stratne to takie, podczas których nie ma szans by zachować poprzednie dane. Najprostszym przykładem będzie tutaj np. zmiana typu danych kolumny. Migracje bezstratne pozwalają natomiast na zachowanie danych, i z nich korzystamy (w sposób całkowicie automatyczny :)) wówczas, gdy np. dodajemy do bazy nową tabelę (a ściślej klasę z modelem tej tabeli). <h2>Migracje mają jeszcze jedną poważną zaletę</h2> Każda zmiana (grupa zmian), zostaje zapamiętana/zapisana, w postaci kodu. Jeżeli w środę dodamy do naszej bazy pięć tabel, w czwartek stwierdzimy, że dwie z nich są zbędne i je usuniemy, a w piątek się zreflektujemy i przytomnie przyznamy, że bez tych dwóch nie da się żyć, to (jeżeli nie usuniemy kodu migracji), będziemy mogli wrócić do zmian ze środy 😉 Migracje zostały dodane do EF, bodajże w wersji 4.3, i od tego czasu są integralną częścią przy podejściu Code First, tworzenia bazy. Co było wcześniej? Z pewnością Chaos… <h2>How to</h2> Na samym początku musimy oczywiście mieć pobraną paczkę z Entity Framework’iem. Polecam pobrać ją za pomocą NuGet‚a Następnie należy zainstalować migracje. Aby to zrobić, wpisujemy w oknie Package Manager Console polecenie : <pre class="language-powershell" tabindex="0"><code class="language-powershell">enable-migrations</code></pre> Jeżeli mamy więcej niż jeden kontekst w aplikacji,rozszerzamy polecenie o jego nazwę w ten sposób: <pre class="language-powershell" tabindex="0"><code class="language-powershell">enable-migrations -ContextTypeName nazwaKontekstu</code></pre> --- W tej chwili mamy zainstalowane migracje. Gdy spojrzymy na Solution Explorer’a zobaczymy, że dla w projekcie dla ktrego instalowaliśmy migracje, został utworzony folder Migrations, w którym, póki co, znajduje się jeden plik Configuration.cs. Ów plik zawiera klasę o takiej samej nazwie. oprócz konstruktora zawiera jedną metodę: Seed(), która jest uruchamiana po każdej migracji bazy, lub przy pierwszym uruchomieniu aplikacji, i w której możemy, np. w celach testowych, utworzyć zawartość naszej bazy, dzięki czemu nie będzie ona całkowicie pusta. Teraz musimy dodać nasze klasy POCO (jeżeli jeszcze ich nie mamy), odzwierciedlające strukturęnaszej bazy danych. Jako przykład niech posłuży tu moja klasa dla tabeli z profilami użytkowników w projekcie HardTraining.  <img src="/static/img/blog/MigrationPoco.png" alt="" class=" postImage" /> <h2>Teraz możemy wprowadzić zmiany na bazie. W tym celu:</h2> Należy dodać migrację. By to zrobić korzystamy z polecenia(cały czas w Package Manager Console): <pre class="language-powershell" tabindex="0"><code class="language-powershell">add-migration NazwaMigracji</code></pre> Gdy powyższe polecenie zostanie wykonane do wcześniej wspomnianego folderu Migrations, zostanie dodany nowy plik składający się z dokładnej daty i czasu oraz nazwy migracji – na poniższym obrazku widzimy plik utworzony po kreacji migracji o nazwie First: <img src="/static/img/blog/migrationfiles.png" alt="" class=" postImage" /> Plik ten zawiera dwie metody Up() i Down(). Jak nietrudno się domyślić, Up() jest używany podczas tworzenia obiektów bazy, a Down() podczas ich usuwania. Teraz ostatni krok. Trzeba zmiany wprowadzić do bazy. Ostatnie polecenie to: <pre class="language-powershell" tabindex="0"><code class="language-powershell">update-database</code></pre> --- Na sam koniec pokażę, w jako sposób można cofnąć się do wybranej migracji. Znowu trzeba coś wpisać w Package Console Manager’a. Jest to: <pre class="language-powershell" tabindex="0"><code class="language-powershell">update-database -TargetMigration:"NazwaMigracjiDoKtórejChcemyWrócić"</code></pre> Proste, prawda? 🙂