Baza danych sql
1. Wprowadzenie
Do tej pory operowaliście na listach. W tej instrukcji pokazane zostanie jak stworzyć bazę danych. W zadaniu skorzystamy z możliwości utworzenia struktury bazy danych z istniejących modeli danych, dzięki wykorzystaniu narządzi entity framework, który automatycznie utworzy nam skrypty migracyjne SQL wraz z bazą danych.
Dodatkowo utworzymy repozytorium generyczne, które pozwoli uniknąć pisania wielokrotnie podobnych zapytań dla identycznych encji bazy danych np. pobierz rekord o zgodnym id.
2. Repozytaria generyczne
W pierwszej kolejności musimy trochę zmienić istniejące modele danych, tak aby mogły tworzyć encję bazy danych. W tym celu należy również nadać odpowiednie atrybuty, aby narzędzie generujące skrypt dobrze wiedziało np. które pole jest kluczem głównym, które obcym.
a. Interfejs dla Modeli danych
W pierwszej kolejności stworzymy interfejs IModel, który odziedziczą wszystkie nasze klasy modeli. Interfejs zawiera deklaracje Id, pozwalając utworzyć generyczne repozytorium ze wspólnym zapytaniem dla wszystkich modeli odnoszącego się do klucza głównego Id. Nadano mu również atrybut [Key] aby generator z całą pewnością potraktował naszą wartość jako klucz główny.
b. generyczne repozytorium
Następnie możemy utworzyć generyczne repozytorium. Do repozytorium generycznego nie potrzebujemy żadnego z modeli danych, wystarczy nam jedynie nasz interfejs IModel oraz klasa bazowa DBContext pochodząca z entity framework.
Jest to całkowicie uniwersalne repozytorium, gdyż będzie pasować do dowolnego kontekstu bazy danych, o którym nawet jeszcze nie wiemy oraz do dowolnego modelu danych dziedziczącego
IModel.
Generyczne repozytorium przyjmuje dwa typy <C,T>.
• C – kontekst bazy danych → który musi dziedziczyć po klasie DBContext oraz posiadać
konstruktor uniwersalny. Wynika to z zapisu where C: DBContext, new()
DBContext w skrócie odpowiada za połączenie do bazy oraz za wymianę danych i odwzorowanie ich na obiekty w C#. W projekcie może być wiele takich kontekstów do jednej lub wielu baz.
• T – model danych → który musi dziedziczyć po interfejsie IModel i musi być klasą, a nie
np. interfejsem. Wynika to z zapisu where T: class, IModel.
Nasze repozytorium posiada również konstruktor, który przyjmuje referencję do kontekstu. Dzięki czemu dwa repozytoria mogą operować na wspólnym kontekście i tym samym połączeniu do bazy danych.
3. Właściwe modele danych i kontekst bay danych
Teraz posiadając podstawy możemy przerobić nasze istniejące już modele danych.W modelu FlatModel, dodano dziedziczenie po IModel, a następnie dodano Id wymagane przez interfejs. Dodatkowo pojawiło się pole kolekcji Residents, oznaczające iż z każdym mieszkaniem będzie można powiązać kilku lokatorów za pomocą klucza obcego. DBContest będzie automatycznie odpytywał bazę danych i wypełniał tą kolekcje rezydentami, którzy będą przypisani do mieszkania.
W modelu ResidentModel dodano dodatkowo pole FlatId, które będzie przechowywać id mieszkania oraz dodano pole FlatModel, do którego DBContekst będzie automatycznie przypisywał referencję do mieszkania na podstawie wartości FlatId. Dodatkowo do pola dodano atrybut ForeignKey, który zmusi DBContext do utworzenia klucza obcego pomiędzy polem FlatId encji ResidentModel, a encją FlatModel.
d. Kontekst bazy danych
Pozostało nam już tylko utworzyć kontekst bazy danych, czyli klasę dziedziczącą po DBContext. Na jej podstawie Framework, będzie mógł stworzyć skrypt generujący bazę danych z dotychczasowego kodu. Jednocześnie klasa ta stanie się pośrednikiem pomiędzy naszym kodem aplikacji, a bazą danych.
W naszym kontekście dodano kolekcje dwóch modeli danych, które następnie utworzą nam dwie encje w bazie danych, będą nimi Flats oraz Residents.
4. Generowanie bazy danych
Posiadając kontekst możemy wygenerować już bazę danych. W pierwszej kolejności musimy uaktywnić migrację. Do tego celu należy uruchomić konsolę Nuget-a.
I wpisać komendę Enable-Migration
Wpisujemy ją zwykle tylko raz, utworzy ona konfigurację migracji i zapisze w katalogu
Migrations. Argument -ContextTypeName wskazuje dla którego kontekstu uruchamiamy
migrację, gdyż może być ich kilka.
Następnie tworzymy skrypt migracyjny komendą Add-Migration.
Dodatkowo do komendy dodaje się nazwę skryptu np. „start”. Tą komendę wywołać należy za każdym razem, gdy dokonamy zmiany w modelach danych, tak aby stworzyć skrypt, który naniesie te zmiany na bazę danych. Nazwy mogą być dowolne, mogą być np. numerem zmian. Wygenerowany skrypt dodaje jedynie zmiany w stosunku do poprzedniego skryptu.
Ostatecznie należy wykonać komendę Update-Database.
Komenda nanosi zmiany na bazę danych, należy wywołać ją za każdym razem po komendzie Add-Migration lub jeśli przenieśliśmy projekt na inny system i chcemy wygenerować nową bazę danych od podstaw.
5. Repozytoria rozszerzające generyczne repo.
Posiadając repozytorium generyczne możemy już z niego korzystać bez potrzeby tworzenia osobnych repozytoriów, które po nich dziedziczą. Jednakże gdy np. brakuje funkcjonalności możemy je rozszerzyć.
Jak widzimy z każdym nowym repozytorium będzie o wiele mniej pisania.
6. Użycie repozytoriów w kontrolerach.
Wykorzystywanie repozytoriów w kontrolerach dużo się nie różni w stosunku do poprzedniego laboratorium, jednakże należy pilnować, aby połączenie z serwerem SQL było rozłączane po każdej akcji na kontrolerze. W innym wypadku można zająć całą limitowaną pulę połączeń do serwera SQL, który odmówi Wam współpracy. Można to zrealizować na dwa sposoby, albo umieszczać obiekt repozytorium w klauzuli using lub wywoływać na repo metodę dispose w trakcie kasowania całego kontrolera.
Dodatkowo należy pamiętać, aby wywołać commit na bazie danych przed końcem obsługi zdarzenia ponieważ wprowadzone zmiany nie zostaną zapamiętane.
Zadanie
• Rozszerzyć aplikację z poprzednich zajęć. I dodać obsługę bazy danych.
• Dla przypomnienia, aplikacja ma służyć do zarządzania biblioteką. Podstawową funkcjonalnością jest wyświetlanie i dodawanie książek do katalogu oraz dodawanie do nich autorów. Dodatkowo aplikacja powinna pozwalać wyszukiwać i usuwać pozycje z katalogu.
