Zawsze w większych aplikacjach spotykamy się z koniecznością stworzenia bazy danych. ASP.net oferuje nam wiele dróg, którymi możemy podążać w celu stworzenia bazy. Entity Framework (Object Relational Mapping) jest jedną z nich. Porównując Entity Framework np. do ADO.net (czyli tworzenia bezpośrednich zapytań) zdecydowanie ułatwia nam pracę i daję sporą wygodę podczas tworzenia bazy. Dlatego właśnie skupimy się tylko na tym Frameworku.

Korzystając z Entity Framework, można pójść trzema drogami.

• sposobem DB First
• sposobem Model First
• sposobem Code First

Sposób DB First – Korzysta się z tej metody głównie wtedy gdy w zespole mamy architekta bazy danych. W takim przypadku korzystamy z bazy, którą stworzył dla nas architekt. Rolą architekta jest odpowiednie przygotowanie struktury bazy (tabele, relacje, itd.)

Sposób Model First – Zazwyczaj korzystamy z niego gdy po prostu lubimy pracę z wizualnym designerem. W takim przypadku sami tworzymy strukturę bazy danych, tworząc wszystko w designerze, a baza generuje się sama na podstawie tego co zrobiliśmy.

Sposób Code First – Jest to zdecydowanie najczęściej spotykana metoda do pracy z bazą danych. Dzieje się tak po prostu dlatego, że programiści ją lubią. Dlaczego? Nie mamy wydzielonych dwóch światów, bazy i kodu, wszystko jest ze sobą połączone. Tworzymy zwykłe klasy obiektów w języku C# i na podstawie właśnie tych klas generowana jest baza danych. Ja sam bardzo cenie Entity Framework i Code First, jeżeli zastanawiasz się, którą metodą tworzyć bazy w Twoich aplikacjach to już chyba znasz odpowiedź 🙂

Dlatego pokażę na średnio zaawansowanym przykładzie w jaki sposób tworzymy bazę danych sposobem Code First.

Stwórzmy bazę danych dla newslettera, w której później będziemy mogli zapisywać imię, nazwisko oraz adres e-mail klienta. Pierwszym krokiem, który będziemy musieli wykonać jest dołączenie do naszego projektu referencji Entity Framework’a. Zrobimy to za pomocą Manage Nuget Packages. Otwieramy MNP. Wpisujemy w zakładkę “Browse” EntityFramework, następnie klikamy przycisk “Install“.

Teraz tworzymy klasę naszego modelu. Jest to tylko wersja pokazowa, wersja końcowa powinna mieć dodane atrybuty Data Annotations. Czyli np. że pole jest wymagane ([Required]), bądź jakiego typu są nasze dane, np. dla adresu e-mail, można byłoby napisać nad zadeklarowaną zmienną “AddresEmail” ciąg “[EmailAddress]”, dzięki, któremu nasza aplikacja wiedziałaby jak prawidłowo walidować tę własność, np. w formularzu.

Żeby korzystanie z bazy danych było w ogóle możliwe musimy stworzyć klasę “kontekstu” – reprezentującą naszą bazę, również dzięki temu później będziemy mogli się do niej odwoływać i na niej operować. Tworzymy w tym celu nowy folder np. DB a w nim naszą klasę kontekstu. Zwróć uwagę na dodane biblioteki.

Właściwość DbSet<TEntity> tworzy dla nas tabelkę w bazie danych. Dobrze, mamy klasę bazową, klasę kontekstu, pytanie czy to nam już wystarcza, …otóż nie. Musimy dodać jeszcze ConnectionString oraz inicjalizator naszej bazy, co bardziej zrozumiale znaczy po prostu coś co stworzy dla nas bazę.

Inicjalizator może mieć różne warianty, tzn. podczas każdego kompilowania naszego projektu:

• może tworzyć bazę, gdy ta nie istnieje,
• może usunąć i stworzyć gdy nasz model uległ zmianom,
• może również za każdym kompilowaniem usunąć i stworzyć bazę od nowa,

Po co te warianty? Często ze względu na wygodne testowanie aplikacji.

Inicjalizator może od razu utworzyć nowe rekordy w naszej bazie danych, jest to świetna sprawa gdy testujemy naszą aplikację. My też stworzymy taki “Seed“.

Powiedzieliśmy sobie troche o inicjalizatorze, więc pora go napisać.

Nasza klasa DBInitializer dziedziczy po CreateDatabaseIfNotExist<nasz_kontekst> dzięki czemu stworzy dla nas bazę danych gdy ta nie będzie wcześniej istniała. Tworzymy również metodę SeedDBData, a w niej nasze przykładowe rekordy, którymi będziemy chcieli wypełnić bazę.

Struktura naszej bazy jest już gotowa, aby w ogóle móc operować bazą trzeba się najpierw z nią połączyć. Dlatego tworzymy w pliku Web.config nasz ConnectionString, przykładowo:

Uwaga! Zwróć uwagę, że nazwa ConnectionStringa jest użyta w klasie kontekstu (“DBContextConnectionString”).

W ten sposób tworzy się bazę, teraz jak jej używać?

Powiedźmy, że w kontrolerze chcemy dobrać się do naszego newslettera. Wyciągnijmy dane w postaci listy. Wyglądałoby to tak:

Zapamiętaj, klasa kontekstu jest tak zaprojektowana, że możesz dowolnie często ją inicjalizować! (w celu połączenia z bazą)

Okej, wiemy jak stworzyć bazę, jak się do niej odwoływać z aplikacji, a co jeśli zmieni się nasz model? Jak zaktualizować bazę danych bez usuwania istniejących rekordów?

W tym celu stosuje się migracje. Jest to bardzo prosty mechanizm, którego nie będę dosadnie tłumaczył, myślę że w sieci znajdziesz mnóstwo informacji na ten temat.

W każdym razie gdy Twój model ulegnie zmianie, tzn. np. w tabeli Newsletters zamiast nazwy pola “Id” będziesz chciał nazwę “ID” to:

• Otwierasz Package Manager Console, pierwsze co musisz zrobić to włączyć migrację. Piszesz polecenie “Enable-Migrations”
• Następnie dodajesz nową migrację poleceniem “Add-Migration NazwaMigracji“
• A ostatecznie “Update-Database“

Model Twojej bazy powinien zostać uaktualniony, a do Twojego projektu powinny się dodać nowe pliki zawierające historie wprowadzanych zmian w bazie. Jest opcja cofnięcia tych zmian poprzez polecenie:

• Update-Database -TargetMigration “NazwaMigracji” –nazwa migracji, której zawiera chciany przez nas model

Podsumowanie

Entity Framework Code First jest niewątpliwie świetną opcją umożliwiającą nam pracę z bazą danych. Jego jedyną wadą jest złożoność, zwróć uwagę ile trzeba wiedzieć, żeby móc z nim pracować (kontekst, inicjalizator, connectionstring). Natomiast wiemy, że do wszystkiego idzie się przyzwyczaić. Zresztą gdy wykonamy kilka projektów tym sposobem na pewno “wejdą nam w krew” nawyki, a cała wiedza stanie się zrozumiała i uporządkowana.

Jerzy Kołakowski

Pasjonat informatyki, bloger.

Full-stack Developer

Technologie:

• ASP.NET MVC
• ASP.NET CORE
• Angular 2+