Внедрение зависимостей в приложении WPF со многими Windows

Question

Правильно ли иметь много фабрик при использовании Dependency Injection с приложением "бизнес-направление"?Под «бизнес-приложением» я подразумеваю приложение, такое как SalesForce.com или CRM-система с множеством функций и связанных окон / форм.На самом деле, SalesForce.com может быть плохим примером.Механизм HTTP GET / POST создает очевидные корни композиции, в которых можно вызывать контейнер DI.Но что из долго работающего приложения WPF, например?Создание графов объектов для всех возможных функций представляется расточительным, когда многие из них не будут вызваны во время этого сеанса, или, возможно, никогда, если роль этого человека ограничивает их использование приложения.

Может показаться, что решение состоит в том, чтобыиспользуйте DI-контейнер для разрешения каждого окна / формы по мере необходимости.Но:

1. Это идет вразрез с принципом DI - разрешать только в корне композиции, в этом случае разрешать родительское окно при запуске приложения.
2. Для этого потребуется фабрики для созданияокна / формы, чтобы предотвратить ссылки на контейнер DI в коде приложения.Кажется, что фабрики будут быстро размножаться.

Кажется, что это увеличивает, а не уменьшает сложность, требуя создания фабрик, чья единственная функция создает "искусственный" корень композиции, чтобы скрыть вызов метода DI Resolve..

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

Честно говоря, приложение сейчас не так уж сложно, и фабрики не сильно усложнят ситуацию.Однако я написал это изолированное приложение, используя DI в качестве учебного упражнения, чтобы представить его себе и небольшой команде разработчиков, в которой я работаю.Большая часть команды не знакома с DI и будет удивляться эффективности DI, когда требуется дополнительный код и классы, чтобы просто скрыть введение контейнера DI.

FWIW, я взял копию Марка Симанна«Внедрение зависимостей в .NET», но пример WPF кажется слишком простым, чтобы охватить этот конкретный сценарий, как можно было ожидать из вводного текста.В его примере есть одна форма MVVM, созданная в событии OnStartup.

Любое понимание приветствуется.Спасибо.

Answer 1

Я все время сталкиваюсь с этим при создании Views / ViewModels в WPF и Silverlight.На самом деле я недавно сделал комментарий к сообщению в блоге Марка Симанна по следующим направлениям:

См. Мой комментарий в понедельник, 19 сентября 2011 г., 10:39:25 .(Сам пост также интересен, обсуждая, где Марк считает допустимым ссылаться на контейнер.)

Если вы используете Castle Windsor для DI, вы можете использовать TypedFactoryFacility, которая позволяет вам избегать ссылки на контейнер вваша фабрика.

Мой общий подход, когда не с использованием Windsor - это просто создать общую абстрактную фабрику, которая вызывает , вызывает Resolve () и с этим покончено.Мне все еще кажется, что расположение службы (то есть «неправильное»), но мне еще предстоит найти другое (не Виндзорское) решение, которое безболезненно кодировать и обслуживать.