Стоит ли устанавливать IoC для не-MVC проектов в .Net? - PullRequest
Новая
       12

Стоит ли устанавливать IoC для не-MVC проектов в .Net?

1 голос
/ 14 марта 2011

Везде, где я ищу информацию о Windsor или Spring.net, всегда ссылаюсь на MVC.Есть ли смысл пытаться реализовать это для проектов веб-форм или wcf?

Ответы [ 5 ]

5 голосов
/ 14 марта 2011

Просто так получилось, что характер веб-приложения ASP.NET MVC очень хорошо подходит для IoC благодаря способу обработки запросов.Можно сказать, что жизненный цикл запуска-запроса-ответа веб-приложения и то, как ASP.NET MVC обрабатывает эти вещи, напрямую соответствуют тому, что Кшиштоф Козьмич называет шаблоном трех вызовов и тому, что Марк Симанн называет Регистрация шаблона Resolve Release .

Однако есть способы следовать этому шаблону даже в приложениях, которые не напрямую поддаются ему - например, в приложениях WinForms, Windowsуслуги и т. д.

Я написал пост в блоге о замке Виндзора TypedFactoryFacility , который является функцией Виндзора, позволяющей вызывать контейнер в истинно IoC-стиле, без кода вашего кода..

Типизированное фабричное средство делает Windsor способным динамически реализовывать интерфейсы, такие как, например, ISomeFactory, делегируя вызовы метода контейнера Resolve, что позволяет вашему коду зависеть только от интерфейса ISomeFactory.

5 голосов
/ 14 марта 2011

IoC одинаково полезен для любого проекта. Проблемы, которые он решает (тестируемость и т. Д. И т. Д.), Не относятся к какому-либо конкретному проекту.

3 голосов
/ 14 марта 2011

Inversion of Control (также известное как Dependency Injection или Стороннее подключение) - это просто способ включить слабая связь .

Насколько я мог определить, есть толькодва способа включить слабую связь: IoC или расположение службы (, которое является анти-шаблоном) . Если вы хотите включить слабую связь в любом приложении, IoC - это способ сделать это.

Свободная связь дает вам множество преимуществ:

  • Тестируемость
  • Позднее связывание
  • Уменьшенная сложность (SOLID) / улучшенная ремонтопригодность
  • Расширяемость
  • Параллельная разработка

Это не такпривязаны к любой конкретной архитектуре, шаблону или типу приложения.

0 голосов
/ 14 марта 2011

IoC не имеет абсолютно никакого отношения к MVC.Это две совершенно разные модели дизайна.

Используете ли вы IoC в приложении, зависит от вашего дизайна.YAGNI?Тогда забудь об этом.Много зависимостей между классами, что затрудняет тестированиеЗарегистрируйтесь немедленно.

Каркасам IoC не важно, какой тип шаблона вы используете для реализации своего приложения.Так что MVC или 10 тыс. Строк кода внутри вашего aspx файла, это не имеет значения.

0 голосов
/ 14 марта 2011

Да, если архитектура вызывает / разрешает это.Это зависит от дизайна всего приложения, а не только от используемой инфраструктуры пользовательского интерфейса.

Например, если проект WebForms все бросает в программный код и напрямую обращается к базе данных из Page_Load и т. Д., То с помощью IoC(или любой вид ре-факторинга) будет трудным.

Однако, если веб-формы, скажем, обращаются к службам или взаимодействуют с моделями, которые обращаются к службам или используют репозитории и т. д., то этиконечные объекты могут быть внедрены с помощью какого-либо локатора службы, такого как инфраструктура IoC.Присоединиться к конструктору классов WebForms может быть нелегко (или даже возможно, я не думаю, что когда-либо пробовал), но вы все равно можете разрешать зависимости внутри классов по мере необходимости (например, свойства классов с поздней привязкой)).

...