Как реализовать DI с помощью DbContext в форме Windows

Question

У меня есть класс, работающий в приложении winforms, которое использует EF Code First. DbContext создается через DI через конструктор класса. Все работает хорошо.

Проблема в том, что данные, на которые ссылаются, также изменяются через веб-сайт, используя тот же шаблон DI с EF Code First, и изменения данных не отражаются в экземпляре контекста в приложении winforms.

Я могу решить эту проблему, воссоздавая объект DbContext в winforms каждый раз, когда я к нему обращаюсь, но мне кажется, это скорее шаблон расположения службы?

Существует ли настоящая техника DI для достижения этой цели? Или я должен удалить контекст из DI и использовать расположение службы?

Answer 1

Проблема в том, что данные, на которые ссылаются, также изменяются через веб-сайт, используя тот же шаблон DI с EF Code First, и изменения данных не отражаются в экземпляре контекста в приложении winforms.

Это проблема с вашими ожиданиями.

Если ваш веб-сервис и приложение оконных форм находятся в отдельных процессах, они не будут совместно использовать данные в памяти.

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

Я могу решить эту проблему, воссоздавая объект DbContext в winforms каждый раз, когда я к нему обращаюсь, но мне кажется, это скорее шаблон расположения службы?

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

Это (не обязательно) шаблон Service Locator, и вам необходимо убедиться, что вы вручную удалили DbContext экземпляры. Я бы дал вам пример кода, но разные контейнеры DI имеют совершенно разные способы выполнения фабричного шаблона.

Или вы можете просто убедиться, что вы фиксируете свои данные на стороне веб-службы, и повторно запрашивать данные на стороне приложения WinForms.

Answer 2

Не были ли вы довольны ответом на другой вопрос (/6564822/kak-zastavit-ef-code-first-zaprashivat-bazu-dannyh), в котором предлагалось использовать отсоединение, AsNoTracking или перезапись изменений?

1) Может быть, вы могли бы передать интерфейс, который может создавать DbContextвместо самого контекста.

using(var context = _contextFactory.Create()) {
  var entity = from table in  context.Blah...;
}

Метод Create может либо создать сам конкретный класс (с небольшим поражением шаблона DI), либо использовать расположение службы для его создания.Не так приятно, но это лучше, чем встраивание вызовов службы определения местоположения повсюду, и все равно означает, что вы сами контролируете жизненный цикл.

2) Измените WinForm для чтения из веб-службы, управляемой веб-сайтом, что фактически аналогично отключению кэширования..

3) Глубоко в сердце MVC (ну, на самом деле, не так глубоко) он напрямую ссылается на контейнер DI и использует его в качестве локатора службы для передачи в качестве аргументов для вновь создаваемых объектов.Технически вы могли бы сделать что-то подобное в WinForms, но для этого понадобилось бы разбить ваше приложение на маленькие кусочки (контроллеры), которые не имеют очень долгого срока службы.Может быть, стоит взглянуть на некоторые MVC / MVP-фреймворки для WinForms, хотя я обнаружил, что больше всего цепляюсь, как увидел после быстрого гугла.