Planowanie programu Entity Framework Core 5.0
Ważny
EF Core 5.0 jest teraz dostępny. Ta strona pozostaje zapisem historycznym planu.
Zgodnie z opisem w procesie planowaniazebraliśmy dane wejściowe od interesariuszy do wstępnego planu wydania EF Core 5.0.
Ważny
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ć przesunięte.
Informacje ogólne
Numer wersji i data wydania
Program EF Core 5.0 jest obecnie zaplanowany do wydania w tym samym czasie co program .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ólnego procesu konwergencji platform do .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 programu 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.
Tematy
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 transparentne mapowanie wiele-do-wielu zgodnie z konwencją
Główni deweloperzy: @smitpatel, @AndriySvyrydi @lajones
Śledzone przez #10508
Rozmiar koszulki: L
Stan: Gotowe
Relacja wiele-do-wielu to najczęściej pożądana funkcja (ok. 506 głosów) w backlogu GitHub.
Obsługa relacji wiele do wielu może być podzielona na trzy główne obszary:
- Pomiń właściwości nawigacji — będą omówione w następnym temacie.
- Typy jednostek zestawu 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 omijania nawigacji, wdrażamy teraz inne aspekty wielu-do-wielu do EF Core 5.0, aby zapewnić pełne środowisko pracy.
Właściwości nawigacji wiele-do-wielu (tzw. "nawigacje z ominięciem")
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 chcących obsługiwać relacje wiele-do-wielu pojawia się wtedy, kiedy nie mogą używać "naturalnych" relacji, bez odwoływania się do tabeli połączeniowej w logice biznesowej, jak na przykład w zapytaniach. Typ encji tabeli sprzężenia może nadal istnieć, ale nie powinien przeszkadzać logice 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 łamiące zgodność w przypadku dostawców baz danych, chociaż powinny być one znacznie mniej poważne niż zmiany wymagane w wersji 3.0.
Filtrowane dołączanie
Główny deweloper: @maumar
Śledzone przez #1833
Rozmiar koszulki: M
Stan: Gotowe
Filtrowane uwzględnienie jest wysoce żądaną funkcją (ok. 376 głosów; druga ogółem), która nie wymaga ogromnej ilości pracy i uważamy, że odblokuje lub ułatwi wiele scenariuszy, które obecnie wymagają filtrów na poziomie modelu lub bardziej złożonych zapytań.
Rozdziel, 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 duże regresje wydajności dla zapytań używających opcji 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 zapytań dotyczących dołączania kolekcji, w przypadkach, gdy pojedyncze zapytanie powoduje słabą 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 powodować pewne zmiany zakłócające działanie aplikacji, ponieważ niektóre z funkcji, które obecnie posiadamy, są zbyt pobłażliwe, co szybko może prowadzić ludzi do pułapek niepowodzeń. 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 z oznaczone area-query w 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
Główni deweloperzy: @bricelam
Śledzone przez #19587
Rozmiar koszulki: L
Stan: Zakres/Gotowe
Określanie zakresu: Funkcjonalność pakietów migracji została odroczona do czasu wydania EF Core 5.0. Jednak w EF Core 5.0 zostanie uwzględnionych kilka innych ukierunkowanych ulepszeń związanych z migracjami i.
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. To powinno:
- Praca w systemach Linux, Mac i Windows
- Stań się dobrym doświadczeniem 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 mogą być liczne drobne ulepszenia w EF Core (na przykład lepsze Migracje na SQLite), wraz ze wskazówkami i długoterminową współpracą z innymi zespołami w celu poprawy doświadczeń końcowych, które wykraczają poza sam EF.
Doświadczenie z platformami 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. Xamarin i inne projekty AOT/konsolidatora są teraz planowane dla EF Core 6.0.
Ważny
Xamarin.Android, Xamarin.iOS, Xamarin.Mac są teraz zintegrowane bezpośrednio z platformą .NET (począwszy od platformy .NET 6) jako .NET dla systemów Android, .NET dla systemów iOS i .NET dla systemu macOS. Jeśli kompilujesz już dziś te typy projektów, powinny one zostać uaktualnione do projektów w stylu zestawu SDK platformy .NET w celu zapewnienia ciągłej pomocy technicznej. Aby uzyskać więcej informacji na temat uaktualniania projektów platformy Xamarin do platformy .NET, zobacz dokumentację Uaktualnianie z platformy Xamarin do platformy .NET & .NET MAUI.
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 mogące inne struktury interfejsu użytkownika
Prawdopodobnie będą to liczne drobne ulepszenia EF Core, wraz z wytycznymi i długotrwałą współpracą z innymi zespołami, aby poprawić kompleksowe doświadczenia wykraczające poza samą platformę EF.
Konkretne obszary, które planujemy przyjrzeć się, to:
- Wdrażanie, w tym doświadczenie korzystania z narzędzi EF, takich jak migracje
- Modele aplikacji, w tym Xamarin i Blazor, i prawdopodobnie inne
- Doświadczenia z SQLite, w tym doświadczenie przestrzenne i odbudowywanie tabel
- AOT i doświadczenia związane z łączeniem
- Integracja diagnostyki, w tym liczniki wydajności
Wydajność
Główny deweloper: @roji
Śledzone przez problemy z oznaczone area-perf w 5.0
Rozmiar koszulki: L
Stan: Zdefiniowano/Ukończono
Określanie zakresu prac: znaczące poprawki wydajności w 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ż odpowiednio dodać liczniki wydajności ADO.NET/EF Core oraz inne dane diagnostyczne, w miarę potrzeb.
Dokumentacja architektury i współtwórców
Główny dokumentalista: @ajcvickers
Śledzone przez #1920
Rozmiar koszulki: L
Status: Wycięty
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ąduje w EF Core 5.0.
Dokumentacja microsoft.Data.Sqlite
Główny dokumentator: @bricelam
Śledzone przez #1675
Rozmiar koszulki: M
Stan: Ukończono. Nowa dokumentacja jest dostępna 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.
Dokumentacja ogólna
Główny dokumentalista: @ajcvickers
Śledzone przez problemy w repozytorium dokumentacji w 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 z oznaczone type-bug w 5.0
Deweloperzy: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers
Rozmiar koszulki: L
Stan: W toku
W chwili pisania mamy 135 usterek przeznaczonych do naprawy w wersji 5.0 (z 62 już naprawionymi), ale istnieje znaczne nakładanie się na Ogólne Usprawnienia Zapytań powyżej.
Tempo napływu (zadania, które przekładają się na pracę w ramach kamienia milowego) wynosiło około 23 zadania miesięcznie podczas prac nad wydaniem wersji 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 type-enhancement z 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 przez problemy oznaczone 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ę im jako cele do osiągnięcia w zależności od postępu w powyższej pracy.
Ponadto zawsze uwzględniamy najczęściej głosowanych kwestii podczas planowania. 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.
