Конфигурация на основе кода

Примечание

Только в EF6 и более поздних версиях. Функции, API и другие возможности, описанные на этой странице, появились в Entity Framework 6. При использовании более ранней версии могут быть неприменимы некоторые или все сведения.

Конфигурацию для приложения Entity Framework можно указать в файле конфигурации (app.config/web.config) или с помощью кода. Последний называется конфигурацией на основе кода.

Конфигурация в файле конфигурации описана в отдельной статье. Файл конфигурации имеет приоритет над конфигурацией на основе кода. Другими словами, если параметр конфигурации задан как в коде, так и в файле конфигурации, используется параметр в файле конфигурации.

Использование DbConfiguration

Конфигурация на основе кода в EF6 и более поздних версиях достигается путем создания подкласса System.Data.Entity.Config.DbConfiguration. При подклассах DbConfigurationследует соблюдать следующие рекомендации:

  • Создайте только один DbConfiguration класс для приложения. Этот класс задает параметры уровня домена приложения.
  • Поместите класс DbConfiguration в ту же сборку, что и класс DbContext . (См. раздел "Перемещение DbConfiguration ", если вы хотите изменить это.)
  • Предоставьте DbConfiguration классу открытый конструктор без параметров.
  • Задайте параметры конфигурации путем вызова защищенных DbConfiguration методов из этого конструктора.

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

Пример

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

using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using System.Data.Entity.SqlServer;

namespace MyNamespace
{
    public class MyConfiguration : DbConfiguration
    {
        public MyConfiguration()
        {
            SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy());
            SetDefaultConnectionFactory(new LocalDbConnectionFactory("mssqllocaldb"));
        }
    }
}

Этот класс настраивает EF для использования стратегии выполнения SQL Azure для автоматического повтора неудачных операций базы данных и использования локальной базы данных для баз данных, созданных по соглашению Code First.

Перемещение DbConfiguration

В некоторых случаях невозможно поместить DbConfiguration класс в ту же сборку, что и класс DbContext . Например, у вас может быть два DbContext класса в разных сборках. Существует два варианта обработки этой функции.

Первый вариант — использовать файл конфигурации, чтобы указать используемый DbConfiguration экземпляр. Для этого задайте атрибут codeConfigurationType раздела entityFramework. Пример:

<entityFramework codeConfigurationType="MyNamespace.MyDbConfiguration, MyAssembly">
    ...Your EF config...
</entityFramework>

Значение codeConfigurationType должно быть полным именем сборки и пространства имен класса DbConfiguration .

Второй вариант — поместить DbConfigurationTypeAttribute в класс контекста. Пример:

[DbConfigurationType(typeof(MyDbConfiguration))]
public class MyContextContext : DbContext
{
}

Значение, переданное атрибуту, может быть вашим DbConfiguration типом, как показано выше, или строкой имени сборки и пространства имен. Пример:

[DbConfigurationType("MyNamespace.MyDbConfiguration, MyAssembly")]
public class MyContextContext : DbContext
{
}

Явное задание DbConfiguration

Существуют некоторые ситуации, когда может потребоваться конфигурация до использования любого DbContext типа. Приведем несколько примеров.

  • Использование DbModelBuilder для создания модели без контекста
  • Использование другого DbContext кода платформы или служебной программы, в котором используется этот контекст перед использованием контекста приложения.

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

  • DbConfiguration Задайте тип в файле конфигурации, как описано в разделе "ПеремещениеDbConfiguration" выше
  • Вызов статического DbConfiguration. Метод SetConfiguration во время запуска приложения

Переопределение DbConfiguration

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

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

  • При запуске приложения (до использования EF) подключаемый модуль или поставщик должен зарегистрировать метод обработчика событий для этого события. (Обратите внимание, что это должно произойти, прежде чем приложение использует EF.)
  • Обработчик событий вызывает ReplaceService для каждой службы, которую необходимо заменить.

Например, чтобы заменить IDbConnectionFactory и DbProviderService зарегистрировать обработчик примерно так:

DbConfiguration.Loaded += (_, a) =>
   {
       a.ReplaceService<DbProviderServices>((s, k) => new MyProviderServices(s));
       a.ReplaceService<IDbConnectionFactory>((s, k) => new MyConnectionFactory(s));
   };

В приведенном выше MyProviderServices коде и MyConnectionFactory представлены реализации службы.

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

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

Также следует помнить о службах, которые выполняются вне приложения, например при выполнении миграций из консоли диспетчера пакетов. При выполнении миграции из консоли она попытается найти свою DbConfiguration. Однако независимо от того, будет ли она получать упаковаемую службу, зависит от того, где зарегистрирован обработчик событий. Если он зарегистрирован в процессе создания кода DbConfiguration , код должен выполняться, и служба должна быть упакована. Как правило, это не так, и это означает, что средства не будут получать упакованные службы.