Планирование для Entity Framework Core 5.0

Важно!

Версия EF Core 5.0 на данный момент уже выпущена. На этой странице будет храниться архивная версия плана.

Как было описано в процессе планирования, мы собрали сведения от заинтересованных лиц в предварительный план для выпуска EF Core 5.0.

Важно!

Этот план отражает все еще продолжающиеся работы. Ничего из приведенного здесь не является обязательством. Этот план является отправной точкой и будет расширяться по мере обучения. Могут быть включены некоторые вещи, пока не запланированные для версии 5.0, и исключены некоторые вещи, уже запланированные для этой версии.

Общая информация

Номер версии и дата выпуска

Сейчас выпуск EF Core 5.0 запланирован на то же самое время, что и.NET 5.0. Версия "5.0" была выбрана для согласования с .NET 5.0.

Поддерживаемые платформы

Планируется, что EF Core 5.0 будет работать на любой платформе .NET Standard 2.1, включая .NET 5.0. Это согласуется с более общей стратегией конвергенции платформ .NET в .NET Core.

EF Core 5.0 не будет работать в .NET Framework.

Критические изменения

EF Core 5.0 будет содержать некоторые критические изменения, но они будут гораздо менее серьезными, чем в случае с EF Core 3.0. Наша цель состоит в том, чтобы позволить подавляющему большинству приложений осуществлять обновление без нарушения работы.

Ожидаются некоторые критические изменения для поставщиков баз данных, особенно связанные с поддержкой метода "одна таблица на тип". Однако мы ожидаем, что обновление поставщика для версии 5.0 потребует меньше работы, чем при обновлении для версии 3.0.

Themes

Мы определили несколько основных областей или тем, которые сформируют основу для крупномасштабных инвестиций в EF Core 5.0.

Полностью прозрачное сопоставление "многие ко многим" в соответствии с соглашением

Ведущие разработчики: @smitpatel, @AndriySvyryd и @lajones

Отслеживается по проблеме #10508

Размер футболки: L

Состояние: Готово

Функция "многие ко многим" является наиболее востребованной (около 506 голосов) в журнале невыполненной работы GitHub.

Поддержку связей "многие ко многим" можно разбить на три основные области:

• Пропуск свойств навигации — рассматривается в следующей теме.
• Типы сущностей контейнера свойств. Они позволяют использовать стандартный тип CLR (например, Dictionary) для экземпляров сущностей таким образом, чтобы для каждого типа сущности не требовался явный тип CLR. Отслеживается по проблеме #9914.
• Средства для простоты настройки связей "многие ко многим".

Помимо поддержки пропуска навигации, эти возможности связи "многие ко многим" перемещаются в EF Core 5.0 для обеспечения эффективной работы.

Свойства навигации "многие ко многим" (или "навигации с пропуском")

Ведущие разработчики: @smitpatel и @AndriySvyryd

Отслеживание с помощью #19003

Размер футболки: L

Состояние: Готово

Как описано в первой теме, поддержка "многие ко многим" имеет несколько аспектов. В этой теме, в частности, отслеживается использование пропуска навигаций. Мы считаем, что наиболее существенным препятствием для тех, кому требуется поддержка типа "многие ко многим", заключается в невозможности использовать "естественные" связи, не ссылаясь на таблицу соединений, в бизнес-логике, такой как запросы. Тип сущности таблицы соединений может по-прежнему существовать, но не должен мешать бизнес-логике.

Сопоставление наследования "одна таблица на тип"

Ведущий разработчик: @AndriySvyryd и @smitpatel

Отслеживание с помощью #2266

Размер футболки: XL

Состояние: Готово

Мы работаем над методом "одна таблица на тип", так как это очень востребованная функция (около 289 голосов; третье место) и для нее требуются некоторые низкоуровневые изменения, которые, по нашему мнению, согласуются с основополагающим характером общего плана по .NET 5. Мы предполагаем, что это приведет к критическим изменениям для поставщиков баз данных, хотя они должны быть гораздо менее серьезными, чем для версии 3.0.

Включение с фильтрацией

Ведущий разработчик: @maumar

Отслеживание с помощью #1833

Размер футболки: M

Состояние: Готово

Включение с фильтрацией — это очень востребованная функция (около 376 голосов; второе место), которая потребует не слишком много работы и, по нашему мнению, позволит реализовать или упростить многие сценарии, в которых сейчас требуются фильтры уровня модели или более сложные запросы.

Разделение Include

Ведущий разработчик: @smitpatel

Отслеживается по проблеме #20892

Размер футболки: L

Состояние: Готово

В EF Core 3.0 изменено поведение по умолчанию для создания отдельного SQL-запроса для заданного запроса LINQ. Это привело к значительному ухудшению производительности запросов, использующих Include для нескольких коллекций.

В EF Core 5.0 мы сохраняем новое поведение по умолчанию. Однако теперь EF Core 5.0 разрешает создание нескольких запросов для коллекции Include, где отдельный запрос приводит к снижению производительности.

Требуются зависимые элементы со связью "один к одному"

Ведущие разработчики: @AndriySvyryd и @smitpatel

Отслеживается по проблеме #12100.

Размер футболки: M

Состояние: Готово

В EF Core 3.0 все зависимые элементы, включая собственные типы, являются необязательными (например, Person.Address может иметь значение NULL). В EF Core 5.0 зависимые элементы можно настроить как обязательные.

Оптимизация ToTable, ToQuery, ToView, FromSql и т. п.

Ведущие разработчики: @AndriySvyryd и @smitpatel

Отслеживание с помощью #17270

Размер футболки: L

Состояние: Готово

В предыдущих выпусках мы уже проделали определенную работу для поддержки необработанного SQL-кода, бесключевых типов и связанных с ними аспектов. Однако при попытке обеспечить работу этих функций как единого целого выявляются недочеты и несоответствия. Версия 5.0 должна устранить эти проблемы и обеспечить удобное определение, перенос и использование различных типов сущностей и связанных с ними запросов и артефактов баз данных. Это также может потребовать внесения изменений в скомпилированный API запросов.

Обратите внимание, что этот пункт может привести к некоторым критическим изменениям на уровне приложения, так как некоторые функциональные возможности, которыми мы сейчас располагаем, допускают слишком вольное обращение с ними, что может быстро привести к сбою. Скорее всего, мы заблокируем некоторые из этих функций и порекомендуем, чем их заменить.

Общие усовершенствования запросов

Ведущие разработчики: @smitpatel и @maumar

Отслеживание с помощью вопроса, отмеченного area-query в вехе 5.0

Размер футболки: XL

Состояние: Готово

Код преобразования запроса для EF Core 3.0 был в значительной степени переписан. Благодаря этому в общем случае код запроса находится в значительно более надежном состоянии. Для версии 5.0 мы не планируем вносить существенные изменения в запросы, за исключением тех, которые необходимы для поддержки метода "одна таблица на тип" и свойств навигации с пропуском. Однако по-прежнему требуется значительная работа, чтобы устранить технический долг, оставшийся после масштабного изменения версии 3.0. Мы также планируем исправить многие ошибки и внести небольшие улучшения для дальнейшего улучшения общего процесса работы с запросами.

Процедура миграция и развертывания

Ведущие разработчики: @bricelam

Отслеживание с помощью #19587

Размер футболки: L

Состояние: область действия или готово

Определение области. Функция пакетов миграции была отложена до момента выпуска EF Core 5.0. Однако в EF Core 5.0 будет включено несколько других улучшений, связанных с миграциями.

Сейчас многие разработчики переносят свои базы данных во время запуска приложения. Это удобно, но не рекомендовано по следующим причинам:

• Несколько потоков/процессов/серверов могут одновременно попытаться перенести базу данных.
• При этом приложения могут попытаться перейти в несогласованное состояние.
• В общем случае разрешения базы данных на изменение схемы не должны предоставляться для выполнения приложения.
• Сложно выполнить возврат к исходному состоянию в случае сбоя.

Мы хотим обеспечить улучшить эту процедуру, чтобы она позволяла легко перенести базу данных во время развертывания. Предъявляются следующие требования:

• Работа в Linux, Mac и Windows.
• Хорошая совместимость с командной строкой.
• Поддержка сценариев с контейнерами.
• Работа с средствами и потоками развертывания, часто применяемыми на практике.
• Интеграция по меньшей мере с Visual Studio.

Результат, скорее всего, будет представлять собой множество небольших улучшений в EF Core (например, улучшенная миграция в SQLite), а также руководства и долгосрочное сотрудничество с другими группами для улучшения комплексных возможностей, выходящих за пределы EF.

Возможности платформ EF Core

Ведущие разработчики: @roji и @bricelam

Отслеживание с помощью #19588

Размер футболки: L

Состояние: область/готово

Определение области. Руководство и примеры платформы публикуются для Blazor, Xamarin, WinForms и WPF. В настоящее время планируется работа над Xamarin и другими AOT и компоновщиками для EF Core 6.0.

У нас есть хорошее руководство по использованию EF Core в традиционных веб-приложениях, работающих по принципу MVC. Рекомендации для других платформ и моделей приложений отсутствуют или устарели. Для EF Core 5.0 мы планируем изучить, улучшить и задокументировать процесс использования EF Core со следующими компонентами:

• Blazor
• Xamarin, в том числе использование AOT или компоновщика
• WinForms/WPF/WinUI и, возможно, другие платформы пользовательского интерфейса

Результат, скорее всего, будет представлять собой множество небольших улучшений в EF Core, а также руководства и долгосрочное сотрудничество с другими группами для улучшения комплексных возможностей, выходящих за пределы EF.

Ниже перечислены конкретные области, которые мы планируем рассмотреть:

• Развертывание, включая интерфейс для использования средств EF, таких как миграции
• Модели приложений, включая Xamarin и Blazor, и, возможно, другие
• Процедуры для SQLite, включая пространственное взаимодействие и перестроение таблиц
• Процедуры для AOT и компоновки
• Интеграция диагностики, включая счетчики производительности

Производительность

Ведущий разработчик: @roji

Отслеживание с помощью вопроса, отмеченного area-perf в вехе 5.0

Размер футболки: L

Состояние: область действия или готово

Определение области. Основные улучшения производительности в поставщике Npgsql завершены. В настоящее время планируется работа над повышением производительности для EF Core 6.0.

Для EF Core мы планируем улучшить набор тестов производительности и внести целевые улучшения производительности для среды выполнения. Кроме того, мы планируем завершить новый API пакетной обработки ADO.NET, который находился на этапе прототипа со времени цикла выпуска версии 3.0. Кроме того, на уровне ADO.NET мы планируем дополнительно улучшить производительность для поставщика Npgsql.

В рамках этой задачи мы также планируем добавить счетчики производительности ADO.NET/EF Core и другие средства диагностики.

Документация по архитектуре и участникам

Ведущий документатор: @ajcvickers

Отслеживание с помощью #1920

Размер футболки: L

Состояние: вырезать

Идея заключается в том, чтобы упростить понимание того, что происходит внутри EF Core. Это может быть полезно любому пользователю EF Core, однако основная мотивация заключается в том, чтобы упростить выполнение внешними пользователями следующих операций:

• Участие в разработке кода EF Core
• Создание поставщиков баз данных
• Создание других расширений

Обновление: К сожалению, этот план был слишком амбициозным. Мы все еще считаем его важным, но, к сожалению, его не удастся реализовать в EF Core 5.0.

Документация по Microsoft.Data.Sqlite

Ведущий документатор: @bricelam

Отслеживание с помощью #1675

Размер футболки: M

Состояние: завершено. Новая документация работает в Microsoft Learn.

Группа EF также владеет поставщиком Microsoft.Data.Sqlite ADO.NET. Мы планируем полностью задокументировать этот поставщик в рамках выпуска 5.0.

Общая документация

Ведущий документатор: @ajcvickers

Отслеживаемые проблемы в репозитории документации в вехе 5.0

Размер футболки: L

Состояние: ход выполнения

Мы уже приступили к обновлению документации для выпусков 3.0 и 3.1. Мы также работаем над следующими задачами:

• Капитальный ремонт статей о начале работы, чтобы сделать их более подходными и проще следовать
• Реорганизация статей для упрощения поиска и добавления перекрестных ссылок
• Добавление дополнительных сведений и уточнений в существующие статьи
• Обновление существующих и добавление новых примеров

Исправление ошибок

Отслеживание с помощью вопроса, отмеченного type-bug в вехе 5.0

Разработчики: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers

Размер футболки: L

Состояние: ход выполнения

На момент написания статьи у нас отобрано 135 ошибок для исправления в выпуске 5.0 (62 уже исправлены), однако они во многом пересекаются с разделом Общие усовершенствования запросов выше.

Скорость поступления (вопросы, превратившиеся в работу в вехе) в рамках выпуска 3.0 составила около 23 вопросов в месяц. Не все из них потребуется исправить в версии 5.0. Ориентировочно в рамках работы над версией 5.0 мы планируем устранить 150 дополнительных проблем.

Небольшие усовершенствования

Отслеживание с помощью вопроса, отмеченного type-enhancement в вехе 5.0

Разработчики: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers

Размер футболки: L

Состояние: Готово

В дополнение к более масштабным функциям, описанным выше, у нас также есть множество небольших усовершенствований, запланированных для версии 5.0, которые призваны исправить мелкие недочеты. Обратите внимание, что многие из этих усовершенствований также входят в более общие темы, описанные выше.

Выход за пределы плана

Отслеживание с помощью вопроса, отмеченного consider-for-next-release

Это исправления ошибок и усовершенствования, которые пока не запланированы для выпуска 5.0, но мы постараемся включить их в зависимости от того, как будет продвигаться описанная выше работа.

Кроме того, при планировании мы всегда учитываем вопросы, набравшие больше всего голосов. Исключение любой из подобных проблем из выпуска всегда дается нелегко, но нам нужен реалистичный план с учетом ресурсов, которыми мы располагаем.

Предложения

Нам важно ваше мнение о планировании. Лучший способ указать важность проблемы — проголосовать за нее на GitHub. Эти данные будут учитываться в процессе планирования для следующего выпуска.