Как избежать хирургии дробовика с помощью Database.SetInitializer

Канонический ответ о том, куда поместить Database.SetInitializerвызовы, находится в Global.asaxдля веб-проектов.Я ищу другой вариант.

Мы используем Entity Framework 4.3.1 с Code First. Мы пишем веб-сервисы и приложения WinForms и обычно помещаем код доступа к данным (, например DbContexts ), в разделяемые библиотеки.

В настоящее время конструкторы наших потомков DbContext выглядят так:

public PricingContext(string connectionString)
    : base(connectionString)
{
    Database.SetInitializer(null);
}

В 95% случаев это правильное значение по умолчанию. 5% времени (какие-то интеграционные тесты, разработка с нуля и т. д. )это не так.

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

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

public PricingContext(string connectionString,
    IDatabaseInitializer databaseInitializer = null)
    : base(connectionString)
{
    Database.SetInitializer(databaseInitializer);
}

Однако переопределение стратегии по умолчанию может включать передачу инициализатора через несколько уровней.

Мы также рассматривали возможность создания инициализатора на основе отражения -, который устанавливал бы для всех контекстов определенную стратегию.

Какова лучшая практика?