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

Примечание

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

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

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

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

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

  • Создайте только один DbConfiguration класс для приложения. Этот класс задает параметры уровня приложения для домена.
  • Поместите свой DbConfiguration класс в ту же сборку, что и DbContext класс. (Если вы хотите изменить этот параметр, см. раздел " Перемещение ".)
  • Присвойте 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 экземпляр. Для этого задайте атрибут Кодеконфигуратионтипе раздела entityFramework. Пример:

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

Значение Кодеконфигуратионтипе должно быть именем сборки и пространством имен 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 . Метод Сетконфигуратион во время запуска приложения

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

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

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

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

Например, для замены 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 код должен выполняться, а служба должна быть заключена в оболочку. Обычно это не так, и это означает, что средства не будут получать упакованную службу.