Поделиться через

Переход с EF6 на EF Core

Entity Framework Core, или сокращенно EF Core, это полная переработка Entity Framework для современных архитектур приложений. Из-за фундаментальных изменений нет прямого пути обновления. Цель этой документации — предоставить комплексное руководство по переносу приложений EF6 в EF Core.

Это важно

Перед началом процесса переноса важно убедиться, что EF Core соответствует требованиям к доступу к данным для приложения. Все необходимые сведения можно найти в документации EF Core.

Предупреждение

EF Core поддерживает только современную платформу .NET и не поддерживает .NET Framework. Таким образом, если проект по-прежнему предназначен для .NET Framework, вам придется перейти на современную .NET, прежде чем начать миграцию из EF6 в EF Core. Обратите внимание, что EF6 поддерживает современную платформу .NET, поэтому сначала можно перейти на современную .NET при сохранении EF6, а затем решить миграцию из EF6 в EF Core.

Причины обновления

Все новые разработки Entity Framework происходят в EF Core. Нет никаких планов по поддержке новых функций в EF6. EF Core выполняется в последних средах выполнения .NET и использует все преимущества среды выполнения, платформы (например, ASP.NET Core или WPF) и функций, относящихся к языку. Ниже приведены некоторые преимущества, которые вы получаете от обновления:

  • Воспользуйтесь преимуществами текущих улучшений производительности в EF Core. Например, один клиент, который перешел с EF6 на EF Core 6, сократил использование тяжелого запроса в 40 раз благодаря функции разделения запросов. Многие клиенты сообщают о значительном повышении производительности, просто перейдя к последней версии EF Core.
  • Используйте новые функции в EF Core. Новые функции не будут добавлены в EF6. Все новые функции, например поставщик Azure Cosmos DB и DbContextFactory, будут добавлены только в EF Core. Полное сравнение EF6 с EF Core, включая несколько функций, эксклюзивных для EF Core, см. в статье "Сравнение EF Core и EF6".
  • Модернизируйте стек приложений с помощью внедрения зависимостей и легко интегрируйте доступ к данным с такими технологиями, как gRPC и GraphQL.

Примечание о миграции

Эта документация использует термины порт и обновление, чтобы избежать путаницы с термином миграция в контексте функции EF Core. Миграции в EF Core несовместимы с миграцией в EF6 Code First из-за значительных улучшений обработки миграции. Рекомендованных способов переноса истории миграций нет, поэтому рекомендуется начинать с "чистого листа" в EF Core. Вы можете сохранять кодовую базу и данные из миграций EF6. Примените окончательную миграцию в EF6, а затем создайте начальную миграцию в EF Core. Вы сможете в будущем отслеживать историю в EF Core.

Действия по обновлению

Путь обновления разделен на несколько документов, упорядоченных на этапе обновления и типа приложения.

Определение "вкуса" EF Core

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

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

База данных в качестве источника истины подразумевает реверс-инжиниринг или автоматическое создание каркаса кода из базы данных. При изменении схемы код либо перегенерируется, либо обновляется для отражения изменений. Это часто называется подход "сначала база данных".

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

В следующей таблице приведены некоторые различия высокого уровня:

Подход Роль разработчика Роль DBA миграции Леса Репо
Сначала код Проектирование сущностей и проверка/настройка созданных миграций Проверка определений и изменений схемы За каждый коммит Не применимо Отслеживание сущностей, DbContext и миграций
База данных в первую очередь Заняться обратной разработкой после изменений и верифицировать созданные сущности Уведомите разработчиков, когда база данных изменится, чтобы пересоздать структуру. Не применимо "На каждое изменение схемы" Отслеживание расширений или частичных классов, расширяющих созданные сущности
Гибрид Обновите конфигурацию Fluent для сопоставления всякий раз, когда изменяются объекты или база данных Сообщите разработчикам, когда база данных изменилась, чтобы они могли обновлять сущности и конфигурацию модели. Не применимо Не применимо Отслеживание сущностей и DbContext

Гибридный подход — это более сложный подход с дополнительными затратами по сравнению с традиционными подходами к коду и базе данных.

Понять влияние перехода от EDMX

EF6 поддерживает специальный формат определения модели с именем Entity Data Model XML (EDMX). Файлы EDMX содержат несколько определений, включая определения концептуальной схемы (CSDL), спецификации сопоставления (MSL) и хранение определений схемы (SSDL). EF Core отслеживает домен, сопоставление и схемы баз данных с помощью внутренних графов моделей и не поддерживает формат EDMX. Многие записи блога и статьи ошибочно утверждают, что EF Core поддерживает только "Code First." EF Core поддерживает все три модели, описанные в предыдущем разделе приложений. Вы можете перестроить модель в EF Core, используя реверс-инжинирование базы данных. Если вы используете EDMX для визуального представления вашей модели сущности, рассмотрите возможность использования открытого исходного кода EF Core Power Tools, который предоставляет аналогичные возможности для EF Core.

Дополнительные сведения о влиянии отсутствия поддержки файлов EDMX см. в руководстве по переносу EDMX .

Выполните действия по обновлению

Это не обязательно для переноса всего приложения. EF6 и EF Core могут работать в одном приложении (см. сведения об использовании EF Core и EF6 в одном приложении). Чтобы свести к минимуму риск, можно рассмотреть следующее:

  1. Перейдите в EF6 в .NET Core, если вы еще не сделали этого.
  2. Перенесите небольшую часть приложения в EF Core и запустите его параллельно с EF6.
  3. В конечном итоге переведите оставшуюся часть кода на EF Core и откажитесь от кода EF6.

Что касается самого порта, на высоком уровне, вы:

  1. Просмотрите изменения поведения между EF6 и EF Core.
  2. Выполните окончательные миграции, если таковые есть, в EF6.
  3. Создайте проект EF Core.
  4. Скопируйте код в новый проект, выполните обратную инженерию или сочетание обоих.
  5. Переименуйте ссылки и сущности и обновите поведение.
    • System.Data.Entity до Microsoft.EntityFrameworkCore
    • Изменение DbContext конструктора для использования параметров и /или переопределения OnConfiguring
    • DbModelBuilder до ModelBuilder
    • Переименование DbEntityEntry<T> в EntityEntry<T>
    • Переход от Database.Log к Microsoft.Extensions.Logging (расширенным) или DbContextOptionsBuilder.LogTo (простым) API
    • Примените изменения для WithRequired и WithOptional (см. здесь)
    • Обновление кода проверки. Нет встроенной проверки данных в EF Core, но это можно сделать самостоятельно.
    • Следуйте всем необходимым шагам для переноса из EDMX.
  6. Выполните определенные действия на основе подхода EF Core:

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