Что такое Виндзорский замок, и почему меня это должно волновать?

Question

Я давний разработчик Windows, поскрежетавший зубами на win32 и ранних версиях COM.Я работаю с .Net с 2001 года, так что я довольно свободно владею C # и CLR.Я никогда не слышал о Castle Windsor, пока не начал участвовать в Stack Overflow.Я читал руководство "Начало работы" в Виндзорском замке, но оно не срабатывает.

Научите этого старого пса новым трюкам и объясните мне, почему я должен интегрировать Castle Windsor в свои корпоративные приложения.

Answer 1

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

Он может предоставить вам объекты с предварительно созданными и подключенными зависимостями прямо там. Весь объектный граф, созданный с помощью отражения и настройки, а не оператора "new".

Начните здесь: http://tech.groups .yahoo.com/group/altdotnet/message/10434

---

Представьте, что у вас есть класс отправки электронной почты.Отправитель электронной почты.Представьте, что у вас есть другой класс WorkflowStepper.Внутри WorkflowStepper вам нужно использовать EmailSender.

Ты всегда можешь сказать new EmailSender().Send(emailMessage);

но что - польза от new - создает ТЕСНУЮ СВЯЗЬ, которую трудно изменить.(в конце концов, это крошечный надуманный пример)

Ну и что, если вместо того, чтобы создавать этого плохого парня внутри WorkflowStepper, вы просто передали его в конструктор?

Итак, тот, кто его вызвал, должен был обновить отправителя электронной почты.

new WorkflowStepper(emailSender).Step()

Представьте, что у вас есть сотни таких маленьких классов, которые несут только одну ответственность (Google SRP)..и вы используете некоторые из них в WorkflowStepper:

new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()

Представьте, что вы не беспокоитесь о деталях EmailSender когда вы пишете WorkflowStepper или AlertRegistry

Вы просто беспокоитесь о концерне, с которым работаете.

Представьте, что весь этот график (дерево) объектов и зависимостей подключается во ВРЕМЯ ВЫПОЛНЕНИЯ, так что, когда вы делаете это:

WorkflowStepper stepper = Container.Get<WorkflowStepper>();

ты получаешь реальную сделку WorkflowStepper со всеми зависимостями, автоматически заполняемыми там, где они вам нужны.

Там нет никакого new

Это просто случается - потому что оно знает, кому что нужно.

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

Answer 2

Я думаю, что IoC - это ступенька в правильном направлении на пути к большей производительности и удовольствию команды разработчиков (включая PM, BA и BOs).Это помогает установить разделение задач между разработчиками и для тестирования.Это дает душевное спокойствие при проектировании, что обеспечивает гибкость, поскольку фреймворки могут входить и выходить.

Лучший способ достичь цели, к которой стремится IoC (CW или Ninject и т.д.), - это устранить политику № 1 и № 2, избавив разработчиков от необходимости надевать фасад ложного понимания при разработке.Не кажется ли вам, что эти два решения не связаны с МоК?Они такие :)

Answer 3

Марк Симанн написал отличную книгу о DI (Dependency Injection), которая является подмножеством IOC.Он также сравнивает несколько контейнеров.Я не могу достаточно рекомендовать эту книгу.Название книги такое:"Внедрение зависимостей в .Net" https://www.manning.com/books/dependency-injection-in-dot-net

Answer 4

Виндзорский замок - это Dependency Injection container. Это означает, что с помощью этого вы можете внедрять свои зависимости и использовать их, не создавая их с помощью ключевого слова new.например ,Предположим, вы написали репозиторий или сервис и хотите использовать его во многих местах, вам нужно сначала зарегистрировать свой сервис / репозиторий, и вы сможете начать использовать его после установки в нужном месте.Вы можете ознакомиться с приведенным ниже руководством, которому я следовал, чтобы изучить виндзорский замок.

Ссылка.

Надеюсь, это поможет вам.

Answer 5

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

Таким образом, либо множество классов без необходимости изменены, вы объединяете значения конфигурации в один большой класс конфигурации, что тоже плохо...или, что еще хуже, перейти на Сервис Локатора!

IoC позволяет вашему классу получать все свои зависимости без этих хлопот, а также более явно управляет временем жизни экземпляров.