Применимость контейнера IoC / демонстрация сценария?

Question

Многие люди в пространстве .NET выбрали Castle Windsor и внедряют его в свои проекты, и в течение прошлого года я пытался понять, почему контейнеры IoC, похоже, рассматриваются как общая "лучшая практика". «? Я прочитал МНОГО рефератов и кратких объяснений причин Виндзора и тому подобного, но каждый последний из них действительно абстрактен и не кажется практичным для большинства проектов, к которым я прикасался, но в последнее время я был сталкиваюсь с множеством проектов, которые используют Виндзор, и я не понимаю, почему.

C # /. NET по своей природе поддерживает интерфейсное кодирование, абстрактные объекты, делегаты и события. Можно реализовать IoC прямо из основного языка и, используя Reflection и т.п., создавать экземпляры неизвестных экземпляров, которые реализуют известные интерфейсы, не прибегая к библиотекам контейнеров IoC.

При применении YAGNI / AYGNI (Вам это нужно?) Я чувствую, что Виндзор был чрезмерно использован. Я, безусловно, вижу преимущества контейнера IoC, но чувствую, что эти преимущества достигаются за счет дополнительных зависимостей и метаданных (специфичные для контейнера IoC атрибуты и методы, вызываемые в основном коде, файлы .config, разбросанные повсюду, app.config / web.config заполнены обязательными тегами, что делает файл .config более сложным для редактирования и т. д.), поэтому я пытаюсь найти компромисс.

Тем не менее, я принимаю возможность того, что я делаю ALL из этих наблюдений / заявлений о невежестве, так как я никогда не был тесно связан с проектом, который использовал Windsor или другую библиотеку контейнеров IoC , Что мне действительно нужно, так это чтобы кто-то продемонстрировал «средний» или «типичный» проект, в котором использовалась библиотека контейнеров IoC, и почему это считается «наилучшей практикой», когда мне кажется, что это делает грязный проект беспорядочным с зависимостями и метаданными.

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

(я не спорю ради спора, а потому, что я действительно хочу получить информацию о том, должен ли я обучаться на контейнерах IoC).

Answer 1

Похоже, вы хотите получить ответ на этот вопрос

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

Замок Виндзор сам использует отражение, так что он действительно является оберткой, чтобы все делать так, как вы хотите. Если вы можете разработать систему, которая проще в использовании, чем CW, вам следует, даже если это будет стоить вам в начальное время запуска. Эта стоимость будет в первую очередь компенсирована кривой обучения CW, так что это будет совсем не то, что изобретать велосипед.

Они говорят себе , что IoC не подходит для небольших проектов

Кроме того, в зависимости от размера и сложность проекта, IoC Контейнер может быть излишним. Предпочитаю используйте его на средних и крупных проектах.

Answer 2

Это не прямой ответ на ваш вопрос, потому что я не знаком с Castle-Windsor, и я не эксперт IoC, но по своему опыту работы с Java-версией Spring я могу сказать, что (я здесь речь идет о весне, так что, может быть, дело не в замке-виндзоре) это делает не только часть внедрения зависимостей, но и сама структура: декларативное управление транзакциями, встроенная структура безопасности, поддержка ORM, встроенная веб-платформа MVC, RMI, веб-службы, электронная почта, AOP и т. д. И все это прекрасно интегрируется с IoC, и работа над приложением действительно проделывает большую работу для вас в большинстве типичных сценариев.

И автоматическое подключение с аннотациями + поддержка IDE (например, IntelliJ IDEA для Spring). Я думаю, что это облегчает проблему с файлом конфигурации.

Я не знаю, является ли Castle-Windsor чем-то, кроме контейнера IoC, но если это так, возможно, он просто еще не существует с точки зрения богатства его функциональности в качестве фреймворка.

Answer 3

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

Я уже давно пытался определить это для себя в посте:

Контейнер инверсии управления (IoC) является неинвазивным настраиваемым интеллектуальным заводским компонентом

Разбив это определение на части, получим

• Фабрика, потому что она отвечает за создание объектов для вас.

• Умный, потому что он понимает, какие у вас зависимости, и рекурсивно создает их для вас.

• Настраивается, потому что вы можете настроить использование через код или файлы конфигурации.

• Неинвазивный, поскольку используемым объектам не нужно знать о контейнере.

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

Вы можете написать гораздо меньше кода, создающего новые объекты. А если вы подумаете о более сложных иерархиях объектов, контейнер IoC может помочь автоматически создать всю цепочку для вас. Это может быть очень мощным.

Вы можете без проблем добавлять смоделированные версии объектов во время тестирования (если вы используете DI и / или SL). Например, создание сервисного локатора для вас тоже решит эту проблему.

Изменение зависимостей, которые вы хотите внедрить в конструктор, не обязательно означает, что вам нужно многократно реорганизовать код.

Вы получаете различные преимущества туннелирования зависимостей через один источник: декораторы, перехватчики, прокси, а также управление образом жизни объекта. С таким контейнером, как Windsor, это позволяет вам делать некоторые сложные вещи по-настоящему просто, с очень небольшим сцеплением

Вы можете отказаться от его концепции средств для плавной интеграции, например, с NHibernate

Answer 4

Предлагаю вам прослушать 2-й эпизод подкаста Radio Engineering. Это целый эпизод по внедрению зависимости. Внедрение зависимостей - наиболее широко известное использование платформ Inversion of Control. Я также рекомендовал бы послушать эпизод DotNetRocks 362, в котором есть Джон Ковач. Здесь - стенограмма шоу.

Теперь побочным эффектом МОК является повышенная тестируемость. Использование контейнера IOC, такого как Castle Windsor, помогает отделить зависимости. Это разделение делает для лучшего модульного теста.

Большинство структур МОК также имеют способы облегчения аспектно-ориентированного программирования. Так что, если вы находитесь в этом, контейнеры IOC могут помочь вам в этом.