Planowanie programu Entity Framework Core 5.0

Ważne

Program EF Core 5.0 został już wydany. Ta strona pozostaje rekordem historycznym planu.

Zgodnie z opisem w procesie planowania zebraliśmy dane wejściowe od uczestników projektu w wstępny plan wydania programu EF Core 5.0.

Ważne

Ten plan jest nadal w toku. Nic tutaj nie jest zobowiązaniem. Ten plan jest punktem wyjścia, który będzie ewoluował, gdy dowiemy się więcej. Niektóre elementy, które nie są obecnie planowane dla wersji 5.0, mogą zostać wciągnięte. Niektóre rzeczy obecnie planowane na 5.0 mogą zostać uderzone.

Informacje ogólne

Numer wersji i data wydania

Program EF Core 5.0 jest obecnie zaplanowany do wydania w tym samym czasie co platforma .NET 5.0. Wersja "5.0" została wybrana tak, aby była zgodna z platformą .NET 5.0.

Obsługiwane platformy

Program EF Core 5.0 ma działać na dowolnej platformie .NET Standard 2.1, w tym .NET 5.0. Jest to część bardziej ogólnej zbieżności platform .NET z platformą .NET Core.

Program EF Core 5.0 nie będzie działać w programie .NET Framework.

Zmiany powodujące niezgodność

Program EF Core 5.0 będzie zawierać pewne zmiany powodujące niezgodność, ale będą one znacznie mniej poważne niż w przypadku platformy EF Core 3.0. Naszym celem jest umożliwienie aktualizacji większości aplikacji bez przerywania pracy.

Oczekuje się, że dostawcy baz danych będą wprowadzać pewne zmiany powodujące niezgodność, zwłaszcza w przypadku obsługi TPT. Oczekujemy jednak, że praca aktualizacji dostawcy dla wersji 5.0 będzie mniejsza niż wymagana do aktualizacji dla wersji 3.0.

Motywy

Wyodrębniliśmy kilka głównych obszarów lub tematów, które będą stanowić podstawę dla dużych inwestycji w EF Core 5.0.

Pełne przezroczyste mapowanie wiele-do-wielu według konwencji

Potencjalni deweloperzy: @smitpatel, @AndriySvyrydi @lajones

Śledzone przez #10508

Rozmiar koszulki: L

Stan: Gotowe

Wiele do wielu jest najbardziej żądaną funkcją (ok. 506 głosów) na liście prac usługi GitHub.

Obsługa relacji wiele-do-wielu można podzielić na trzy główne obszary:

• Pomiń właściwości nawigacji — pokryte następnym motywem.
• Typy jednostek worka właściwości. Umożliwiają one używanie standardowego typu CLR (np. Dictionary) dla wystąpień jednostek, tak aby jawny typ CLR nie był wymagany dla każdego typu jednostki. Śledzone przez #9914.
• Cukier do łatwej konfiguracji relacji wiele-do-wielu.

Oprócz obsługi nawigacji pomiń teraz ściągamy te inne obszary wiele do wielu do platformy EF Core 5.0, aby zapewnić pełne środowisko pracy.

Właściwości nawigacji wiele do wielu (np. "pomiń nawigację")

Potencjalni deweloperzy: @smitpatel i @AndriySvyryd

Śledzone przez #19003

Rozmiar koszulki: L

Stan: Gotowe

Jak opisano w pierwszym temacie, obsługa wiele do wielu ma wiele aspektów. Ten motyw specjalnie śledzi korzystanie z nawigacji pomiń. Uważamy, że najbardziej znaczący bloker dla osób, które chcą obsługiwać wiele-do-wielu, nie jest w stanie używać "naturalnych" relacji, bez odwoływania się do tabeli sprzężenia w logice biznesowej, takiej jak zapytania. Typ jednostki tabeli sprzężenia może nadal istnieć, ale nie powinien być zgodny ze sposobem logiki biznesowej.

Mapowanie dziedziczenia tabeli na typ (TPT)

Główny deweloper: @AndriySvyryd i @smitpatel

Śledzone przez #2266

Rozmiar koszulki: XL

Stan: Gotowe

Robimy TPT, ponieważ jest to zarówno bardzo żądana funkcja (ok. 289 głosów; trzeci ogólny) i dlatego, że wymaga pewnych zmian niskiego poziomu, które uważamy za właściwe dla podstawowego charakteru ogólnego planu platformy .NET 5. Oczekujemy, że spowoduje to zmiany powodujące niezgodność dla dostawców baz danych, chociaż powinny one być znacznie mniej poważne niż zmiany wymagane dla wersji 3.0.

Filtrowane dołączanie

Główny deweloper: @maumar

Śledzone przez #1833

Rozmiar koszulki: M

Stan: Gotowe

Filtrowane uwzględnij jest wysoce żądaną funkcją (ok. 376 głosów; druga ogólna) nie jest ogromną ilością pracy i uważamy, że odblokujemy lub ułatwimy wiele scenariuszy, które obecnie wymagają filtrów na poziomie modelu lub bardziej złożonych zapytań.

Podziel uwzględnij

Główny deweloper: @smitpatel

Śledzone przez #20892

Rozmiar koszulki: L

Stan: Gotowe

Program EF Core 3.0 zmienił domyślne zachowanie, aby utworzyć pojedyncze zapytanie SQL dla danego zapytania LINQ. Spowodowało to regresję wydajności dla zapytań, które używają funkcji Uwzględnij dla wielu kolekcji.

W programie EF Core 5.0 zachowujemy nowe zachowanie domyślne. Jednak program EF Core 5.0 umożliwia teraz generowanie wielu zapytań dla kolekcji Obejmuje, gdzie pojedyncze zapytanie powoduje niską wydajność.

Wymagane zależności jeden do jednego

Potencjalni deweloperzy: @AndriySvyryd i @smitpatel

Śledzone przez #12100

Rozmiar koszulki: M

Stan: Gotowe

W programie EF Core 3.0 wszystkie elementy zależne, w tym typy własności, są opcjonalne (np. Person.Address może mieć wartość null). W programie EF Core 5.0 zależności można skonfigurować zgodnie z potrzebami.

Racjonalizacja tabeli ToTable, ToQuery, ToView, FromSql itp.

Potencjalni deweloperzy: @AndriySvyryd i @smitpatel

Śledzone przez #17270

Rozmiar koszulki: L

Stan: Gotowe

Poczyniliśmy postępy w poprzednich wersjach w celu obsługi nieprzetworzonych typów SQL, typów bez kluczy i powiązanych obszarów. Istnieją jednak zarówno luki, jak i niespójności w sposobie, w jaki wszystko działa razem jako całość. Celem 5.0 jest naprawienie tych elementów i utworzenie dobrego środowiska do definiowania, migrowania i używania różnych typów jednostek oraz skojarzonych z nimi zapytań i artefaktów bazy danych. Może to również obejmować aktualizacje interfejsu API skompilowanego zapytania.

Należy pamiętać, że ten element może spowodować pewne zmiany powodujące niezgodność na poziomie aplikacji, ponieważ niektóre funkcje, które obecnie mamy, są zbyt permissywne, dzięki czemu mogą szybko prowadzić ludzi do dołków awarii. Prawdopodobnie zablokujemy niektóre z tych funkcji wraz ze wskazówkami dotyczącymi tego, co należy zrobić.

Ogólne ulepszenia zapytań

Potencjalni deweloperzy: @smitpatel i @maumar

Śledzone przez problemy oznaczone etykietą area-query w kamieniu milowym 5.0

Rozmiar koszulki: XL

Stan: Gotowe

Kod tłumaczenia zapytań został szeroko przepisany dla platformy EF Core 3.0. Kod zapytania jest zazwyczaj w znacznie bardziej niezawodnym stanie z tego powodu. W wersji 5.0 nie planujemy wprowadzania istotnych zmian zapytań poza tymi, które są potrzebne do obsługi TPT i pomijania właściwości nawigacji. Jednak nadal jest wymagana znaczna praca w celu naprawienia pewnego długu technicznego pozostawionego z remontu 3.0. Planujemy również naprawienie wielu usterek i zaimplementowanie drobnych ulepszeń w celu dalszego ulepszania ogólnego środowiska zapytań.

Migracje i środowisko wdrażania

Deweloperzy potencjalnych klientów: @bricelam

Śledzone przez #19587

Rozmiar koszulki: L

Stan: Zakres/Gotowe

Określanie zakresu: funkcja pakietów migracji została odroczona do czasu wydania programu EF Core 5.0. Jednak kilka innych ukierunkowanych ulepszeń związanych z migracjami zostanie uwzględnionych w programie EF Core 5.0

Obecnie wielu deweloperów migruje swoje bazy danych w czasie uruchamiania aplikacji. Jest to łatwe, ale nie jest zalecane, ponieważ:

• Wiele wątków/procesów/serwerów może próbować migrować bazę danych jednocześnie
• Aplikacje mogą próbować uzyskać dostęp do niespójnego stanu, gdy dzieje się tak
• Zazwyczaj uprawnienia bazy danych do modyfikowania schematu nie powinny być przyznawane na potrzeby wykonywania aplikacji
• Trudno jest przywrócić czysty stan, jeśli coś pójdzie nie tak

Chcemy zapewnić lepsze środowisko pracy, które umożliwia łatwą migrację bazy danych w czasie wdrażania. Powinno to:

• Praca w systemach Linux, Mac i Windows
• Dobre doświadczenie w wierszu polecenia
• Obsługa scenariuszy z kontenerami
• Praca z często używanymi rzeczywistymi narzędziami/przepływami wdrażania
• Integracja z co najmniej programem Visual Studio

Wynikiem może być wiele małych ulepszeń w programie EF Core (na przykład lepsze migracje na sqlite) wraz ze wskazówkami i długoterminowymi współpracami z innymi zespołami w celu poprawy kompleksowego środowiska, które wykraczają poza platformę EF.

Środowisko platform EF Core

Potencjalni deweloperzy: @roji i @bricelam

Śledzone przez #19588

Rozmiar koszulki: L

Stan: Zakres/Gotowe

Określanie zakresu: wskazówki dotyczące platformy i przykłady są publikowane dla platformy Blazor, Xamarin, WinForms i WPF. Środowisko Xamarin i inne prace AOT/konsolidatora są teraz planowane dla platformy EF Core 6.0.

Mamy dobre wskazówki dotyczące korzystania z platformy EF Core w tradycyjnych aplikacjach internetowych przypominających mvC. Wskazówki dotyczące innych platform i modeli aplikacji są brakujące lub nieaktualne. W przypadku programu EF Core 5.0 planujemy zbadać, ulepszyć i udokumentować środowisko korzystania z platformy EF Core z:

• Blazor
• Środowisko Xamarin, w tym używanie scenariusza AOT/konsolidatora
• WinForms/WPF/WinUI i ewentualnie inne struktury U.I.

Prawdopodobnie będzie to wiele małych ulepszeń platformy EF Core wraz ze wskazówkami i długoterminowymi współpracami z innymi zespołami w celu poprawy kompleksowego środowiska, które wykraczają poza platformę EF.

Konkretne obszary, które planujemy przyjrzeć się, to:

• Wdrażanie, w tym środowisko korzystania z narzędzi EF, takich jak migracje
• Modele aplikacji, w tym Xamarin i Blazor, i prawdopodobnie inne
• Środowiska SQLite, w tym środowisko przestrzenne i ponowne kompilowanie tabeli
• Środowisko AOT i łączenie
• Integracja diagnostyki, w tym liczniki wydajności

Wydajność

Główny deweloper: @roji

Śledzone przez problemy oznaczone etykietą area-perf w kamieniu milowym 5.0

Rozmiar koszulki: L

Stan: Zakres/Gotowe

Określanie zakresu: główne ulepszenia wydajności dostawcy npgsql zostały ukończone. Inne prace dotyczące wydajności są teraz planowane dla platformy EF Core 6.0.

W przypadku platformy EF Core planujemy ulepszyć zestaw testów porównawczych wydajności i wprowadzić ukierunkowane ulepszenia wydajności w środowisku uruchomieniowym. Ponadto planujemy ukończenie nowego interfejsu API przetwarzania wsadowego ADO.NET, który został prototypowany podczas cyklu wydawania wersji 3.0. Ponadto w warstwie ADO.NET planujemy dodatkowe ulepszenia wydajności dostawcy npgsql.

W ramach tej pracy planujemy również dodać odpowiednio ADO.NET/EF podstawowe liczniki wydajności i inne dane diagnostyczne.

Dokumentacja dotycząca architektury/współautora

Dokumentator potencjalnych klientów: @ajcvickers

Śledzone przez #1920

Rozmiar koszulki: L

Stan: Wytnij

Chodzi o to, aby ułatwić zrozumienie tego, co dzieje się wewnętrznych platformy EF Core. Może to być przydatne dla każdego, kto korzysta z platformy EF Core, ale główną motywacją jest ułatwienie osobom zewnętrznym:

• Współtworzenie kodu platformy EF Core
• Tworzenie dostawców bazy danych
• Kompilowanie innych rozszerzeń

Aktualizacja: Niestety, ten plan był zbyt ambitny. Nadal wierzymy, że jest to ważne, ale niestety nie wylądowa z EF Core 5.0.

Dokumentacja microsoft.Data.Sqlite

Dokumentator potencjalnych klientów: @bricelam

Śledzone przez #1675

Rozmiar koszulki: M

Stan: Ukończono. Nowa dokumentacja jest aktywna w witrynie Microsoft Learn.

Zespół EF jest również właścicielem dostawcy ADO.NET Microsoft.Data.Sqlite. Planujemy w pełni udokumentować tego dostawcę w ramach wersji 5.0.

Ogólna dokumentacja

Dokumentator potencjalnych klientów: @ajcvickers

Śledzone przez problemy w repozytorium dokumentacji w kamieniu milowym 5.0

Rozmiar koszulki: L

Stan: W toku

Jesteśmy już w trakcie aktualizowania dokumentacji dla wersji 3.0 i 3.1. Pracujemy również nad:

• Przegląd artykułów wprowadzających, aby uczynić je bardziej przystępnymi/łatwiejszymi do naśladowania
• Reorganizacja artykułów w celu ułatwienia znajdowania i dodawania odwołań krzyżowych
• Dodawanie dodatkowych szczegółów i wyjaśnień do istniejących artykułów
• Aktualizowanie przykładów i dodawanie kolejnych przykładów

Naprawianie usterek

Śledzone przez problemy oznaczone etykietą type-bug w kamieniu milowym 5.0

Deweloperzy: @roji, , @maumar@bricelam, @smitpatel, , @AndriySvyryd@ajcvickers

Rozmiar koszulki: L

Stan: W toku

W momencie pisania tekstu mamy 135 usterek sklasyfikowanych w wersji 5.0 (z 62 już naprawionymi), ale w powyższej sekcji Ogólne ulepszenia zapytań nakładają się na siebie.

Szybkość przychodząca (problemy, które kończą się jako praca w kamieniu milowym) wynosiła około 23 problemów miesięcznie w trakcie wydania 3.0. Nie wszystkie te elementy należy naprawić w wersji 5.0. Zgodnie z przybliżonym oszacowaniem planujemy rozwiązać dodatkowe 150 problemów w przedziale czasowym 5.0.

Małe ulepszenia

Śledzone przez problemy oznaczone etykietą type-enhancement w kamieniu milowym 5.0

Deweloperzy: @roji, , @maumar@bricelam, @smitpatel, , @AndriySvyryd@ajcvickers

Rozmiar koszulki: L

Stan: Gotowe

Oprócz większych funkcji opisanych powyżej mamy również wiele mniejszych ulepszeń zaplanowanych na 5,0, aby naprawić "cięcia papieru". Należy pamiętać, że wiele z tych ulepszeń jest również objętych bardziej ogólnymi motywami opisanymi powyżej.

Poniżej linii

Śledzone według problemów oznaczonych etykietą consider-for-next-release

Są to poprawki błędów i ulepszenia, które nie są obecnie zaplanowane dla wersji 5.0, ale przyjrzymy się jako cele rozproszone w zależności od postępu wykonanego powyżej pracy.

Ponadto podczas planowania zawsze bierzemy pod uwagę najbardziej przegłosowane kwestie . Cięcie któregokolwiek z tych problemów z wydania jest zawsze bolesne, ale potrzebujemy realistycznego planu dla posiadanych zasobów.

Sugestie

Twoja opinia na temat planowania jest ważna. Najlepszym sposobem wskazania znaczenia problemu jest głosowanie (kciuki w górę) dla tego problemu w usłudze GitHub. Te dane zostaną następnie wprowadzone do procesu planowania na potrzeby następnej wersji.