О сценариях внедрения зависимостей, IRepository и миграции EF

Меня смущает то, как EF Migrations обрабатывает сценарии, в которых мои репозитории являются универсальными (IRepository‹>) и внедряются во время выполнения с помощью выбранного мной инструмента инжектора зависимостей. Вы знаете, что база данных обновляется/синхронизируется миграциями с использованием трех элементов:

  1. Модель базы данных (контекст объекта и свойства DbSet‹>)
  2. Классы миграции внутри папки Migration
  3. Уже существующая база данных (если есть)

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

У меня есть решение со следующими проектами: Core.Entities, Core.RepositoryInterfaces и Infraestructure.RepositoryEF, Infraestructure.DependencyResolution и UI.WebSite.

Как вы знаете, репозитории вводятся в конструктор класса, когда они мне нужны:

  private IRepository<Product> _productrepo;  
  Public Test(IRepository<Product> productRepo)
  {
            _productRepo = productrepo;
   }

Возникает вопрос: как миграция может обновить базу данных, поскольку контекст моего объекта не имеет свойств dbset‹> (мой инструмент зависимостей внедряет эти репозитории во время выполнения)?

Спасибо за вашу ценную помощь.


dependency-injection entity-framework entity-framework-migrations irepository
person reliasr    schedule 22.06.2013    source источник
comment
@ Стивен Я уже отредактировал вопрос. Внутри моего проекта я прошу такие службы, как IOrderService, а Ninject позаботится об аргументах конструктора: (продукт IRepository‹Product›, IUnitOfWork uok). Это означает, что у меня нет исходной структуры DbContext, которая обычно содержит таблицы: Dbcontext.Dbset‹Product› и т. д. Процесс миграции считывает список таблиц внутри Dbcontext, чтобы обновить физическую базу данных, и я не иметь такой дизайн. Спасибо.   -  person reliasr    schedule 22.06.2013
comment
Но у вас есть (свободно) сопоставления, не так ли? Или вы ищете ограниченные контексты?   -  person Gert Arnold    schedule 23.06.2013

Ответы (1)


arrow_upward
1
arrow_downward

Я думаю, что первая миграция кода не обновит вашу модель, если у вас есть пустой объект dbcontext (я имею в виду без свойств dbset). Таким образом, один из способов справиться с этим сценарием, когда вы используете шаблон репозитория и внедряете объект dbcontext в каждый запрошенный репозиторий:

Создайте два объекта dbcontext, один для времени разработки (devdbcontext), а другой для производственной среды (proddbcontext).

  1. Devdbcontext будет разработан со свойствами dbset, таким образом рабочий процесс миграции будет обычным во время разработки; он обнаружит изменения модели и воссоздаст базу данных и т. д. Этот объект будет выбран, когда вы находитесь в режиме ОТЛАДКИ (#if DEBUG)

  2. Proddbcontext будет производным объектом dbcontext без свойств dbset и будет выбран, когда вы находитесь в режиме RELEASE (#if RELEASE). Для обновления производственной базы данных я сгенерирую СЦЕНАРИЙ БАЗЫ ДАННЫХ и установлю инициализатор базы данных на NULL.

Что вы думаете об этом решении?

person reliasr    schedule 24.06.2013