Правильный способ внедрения зависимостей в приложении Windows Client (WPF)
Я привык к IoC / DI в веб-приложениях - в основном Ninject с MVC3. Мой контроллер создан для меня, заполнен всеми установленными зависимостями, подзависимостями и т. Д.
Однако в толстом клиентском приложении все иначе. Я должен создать свои собственные объекты или вернуться к подходу в стиле локатора служб, при котором я прошу ядро (возможно, через какой-то интерфейс, чтобы обеспечить возможность тестирования) предоставить мне объект с зависимостями.
Однако я видели несколько мест, где Service Locator был описан как анти-шаблон.
Итак, мой вопрос: если я хочу извлечь выгоду из Ninject в моем толстом клиентском приложении, есть ли лучший / более правильный способ получить все это?
- Тестируемость
- Правильный DI / IoC
- Наименее возможная степень связи
Обратите внимание, что я говорю не только о MVVM здесь и о преобразовании моделей представления в представления. Это, в частности, вызвано необходимостью предоставить объект типа репозитория из ядра, а затем получить объекты, извлеченные из этого репозитория, с введенными функциями (данные, конечно, поступают из базы данных, но им также нужны некоторые объекты в качестве параметров в зависимости от состояния мира, и Ninject знает, как это обеспечить). Могу ли я каким-то образом сделать это, не оставляя и репозитории, и сущности как непроверяемые беспорядки?
Если что-то неясно, дайте мне знать. Спасибо!
ИЗМЕНИТЬ 14 ИЮЛЯ
Я уверен, что два предоставленных ответа, вероятно, верны. Однако каждая клеточка моего тела борется с этим изменением; Некоторые из них, вероятно, вызваны недостатком знаний, но есть также одна конкретная причина, по которой мне трудно увидеть элегантность этого способа ведения дел;
Я недостаточно хорошо объяснил это в исходном вопросе, но Дело в том, что я пишу библиотеку, которая будет использоваться несколькими (сначала 4-5, может, позже) клиентскими приложениями WPF. Все эти приложения работают на одной и той же модели предметной области и т. Д., Поэтому хранение всего этого в одной библиотеке - единственный способ оставаться СУХИМ. Однако есть вероятность, что клиенты этой системы напишут своих собственных клиентов - и я хочу, чтобы у них была простая, чистая библиотека, с которой можно было бы общаться. Я не хочу заставлять их использовать DI в их корне композиции (используя такой термин, как Марк Симан в его книге) - потому что это ОГРОМНО усложняет ситуацию по сравнению с тем, что они просто создают MyCrazySystemAdapter () и используют его.
Теперь MyCrazySystemAdapter (имя выбрано, потому что я знаю, что люди не согласятся со мной здесь) должен состоять из подкомпонентов и собираться вместе с использованием DI. Сам MyCrazySystemAdapter не нужно вводить. Это единственный интерфейс, который клиенты должны использовать для связи с системой. Таким образом, клиент с радостью должен получить один из них, DI происходит как по волшебству за кулисами, а объект состоит из множества различных объектов с использованием передовых методов и принципов.
Я понимаю, что это будет противоречивый способ желания что-то делать. Однако я также знаю людей, которые станут клиентами этого API. Если они увидят, что им нужно изучить и подключить систему DI, и заранее создать всю структуру объектов в своей точке входа в приложение (корень композиции), вместо того, чтобы создавать новый отдельный объект, они покажут мне средний палец и напрямую связываться с базой данных и портить вещи способами, которые вы даже представить себе не можете.
TL; DR: Доставка правильно структурированного API - слишком большая проблема для клиента. Мой API должен предоставлять единый объект, созданный за кулисами с использованием DI и надлежащих практик, который они могут использовать. Реальный мир иногда превосходит желание построить все наоборот, чтобы оставаться верным шаблонам и практикам.