Udostępnij za pośrednictwem


Tworzenie modelu

Model rozwiązania EF przechowuje szczegółowe informacje o mapowaniu klas aplikacji i właściwości na tabele i kolumny bazy danych. Istnieją dwa główne sposoby tworzenia modelu rozwiązania EF:

  • Używanie funkcji Code First: Deweloper pisze kod w celu określenia modelu. Rozwiązanie EF generuje modele i mapowania w czasie wykonywania, bazując na klasach jednostek i dodatkowej konfiguracji modelu dostarczonej przez dewelopera.

  • Używanie projektanta rozwiązania EF: Deweloper rysuje pola i linie w celu określenia modelu przy użyciu projektanta rozwiązania EF. Wynikowy model jest przechowywany jako kod XML w pliku z rozszerzeniem EDMX. Obiekty domeny aplikacji są zwykle generowane automatycznie na podstawie modelu koncepcyjnego.

Przepływy pracy rozwiązania EF

Oba te podejścia można stosować dla istniejącej bazy danych lub podczas tworzenia nowej bazy danych, co oznacza, że istnieją 4 różne przepływy pracy. Ustal, który z nich jest najlepszy dla Ciebie:

Chcę tylko pisać kod... Chcę użyć projektanta...
Tworzę nową bazę danych Użyj funkcji Code First, aby zdefiniować model w kodzie, a następnie wygenerować bazę danych. Użyj funkcji Model First, aby zdefiniować model przy użyciu pól i linii, a następnie wygenerować bazę danych.
Chcę uzyskać dostęp do istniejącej bazy danych Użyj funkcji Code First, aby utworzyć model oparty na kodzie, który będzie mapowany na istniejącą bazę danych. Użyj funkcji Database First, aby utworzyć model złożony z pól i linii, który będzie mapowany na istniejącą bazę danych.

Obejrzyj film: Którego przepływu pracy rozwiązania EF mam użyć?

W tym krótkim filmie wyjaśniono różnice i sposób ustalania odpowiedniej metody.

Prezenter: Rowan Miller

Which Workflow ThumbZIP | MP4 | ZIP

Jeśli po obejrzeniu filmu nadal nie możesz zdecydować, czy chcesz użyć projektanta rozwiązania EF, czy funkcji Code First, poznaj obie te metody!

Co kryje się wewnątrz

Niezależnie od tego, czy używasz funkcji Code First, czy projektanta rozwiązania EF, model rozwiązania EF zawsze ma kilka składników:

  • Obiekty domeny lub typy jednostek aplikacji. Jest to często nazywane warstwą obiektów

  • Model koncepcyjny obejmujący typy jednostek i relacji specyficznych dla domeny, opisany przy użyciu modelu Entity Data Model. Ta warstwa jest często określana literą „K” (koncepcyjny).

  • Model magazynowania reprezentujący tabele, kolumny i relacje zgodnie z definicjami w bazie danych. Ta warstwa jest często określana literą „M” (magazynowanie).

  • Mapowanie między modelem koncepcyjnym a schematem bazy danych. To mapowanie jest często określane jako mapowanie „K-M”.

Aparat mapowania rozwiązania EF stosuje mapowanie „K-M”, aby przekształcić operacje na jednostkach — takie jak tworzenie, odczytywanie, aktualizowanie i usuwanie — w równoważne operacje na tabelach w bazie danych.

Mapowanie między modelem koncepcyjnym a obiektami aplikacji jest często określane jako mapowanie „O-K”. W porównaniu z mapowaniem „K-M” mapowanie „O-K” jest niejawne i ma formę „jeden do jednego”: jednostki, właściwości i relacje zdefiniowane w modelu koncepcyjnym muszą pasować do struktury i typów obiektów platformy .NET. W rozwiązaniu EF4 i nowszych wersjach warstwa obiektów może zawierać proste obiekty z właściwościami bez żadnych zależności od rozwiązania EF. Są one zwykle określane jako zwykłe stare obiekty CLR (POCO, Plain-Old CLR Objects), a mapowanie typów i właściwości jest wykonywane na podstawie konwencji dopasowywania nazw. Wcześniej, w rozwiązaniu EF 3.5 istniały określone ograniczenia dla warstwy obiektów — na przykład jednostki musiały pochodzić od klasy EntityObject i mieć atrybuty rozwiązania EF, aby można było zaimplementować mapowanie „O-K”.