Я давний разработчик Windows, вырезав зубы на win32 и в начале COM. Я работаю с .Net с 2001 года, поэтому я довольно свободно владею С# и CLR. Я никогда не слышал о Castle Windsor, пока не начал участвовать в Stack Overflow. Я прочитал руководство Castle Windsor "Начало работы", но он не щелкнул.
Научите эту старую собаку новым трюкам и скажите, почему я должен интегрировать Castle Windsor в свои корпоративные приложения.
Замок Виндзор - это инверсия инструмента управления. Есть и другие подобные.
Он может предоставить вам объекты с предварительно построенными и предварительно подключенными зависимостями прямо там. Весь граф объектов, созданный с помощью отражения и конфигурации, а не "новый".
Начните здесь: http://tech.groups.yahoo.com/group/altdotnet/message/10434
Представьте, что у вас есть класс отправки электронной почты. EmailSender. Представьте, что у вас есть еще один класс WorkflowStepper. Внутри WorkflowStepper вам необходимо использовать EmailSender.
Вы всегда можете сказать new EmailSender().Send(emailMessage);
но это - использование new - создает ТЯЖЕЛОЕ СОЕДИНЕНИЕ, которое трудно изменить. (это крошечный надуманный пример)
Итак, что, если вместо того, чтобы вводить этого плохого мальчика в WorkflowStepper, вы просто передали его в конструктор?
Итак, кто бы это ни называл, должен был обновить EmailSender.
new WorkflowStepper(emailSender).Step()
Представьте, что у вас есть сотни этих маленьких классов, которые имеют только одну ответственность (google SRP).. и вы используете несколько из них в WorkflowStepper:
new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()
Представьте, что вы не беспокоитесь о деталях EmailSender при написании WorkflowStepper или AlertRegistry
Вы просто беспокоитесь о том, с чем вы работаете.
Представьте, что весь этот граф (дерево) объектов и зависимостей подключается в RUN TIME, так что когда вы это делаете:
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
вы получаете реальную сделку WorkflowStepper со всеми зависимостями, автоматически заполненными там, где они вам нужны.
newЭто просто происходит - потому что он знает, в чем нуждается.
И вы можете написать меньше дефектов с более совершенным, сухим кодом в проверяемом и повторяемом виде.
Если вы являетесь полным новичком с IOC, тогда не начинайте с Castle Windsor, так как документация оставляет желать лучшего и его медленное (оно использует Reflection).
Я бы рекомендовал NInject, потому что:
Чтобы начать работу, нажмите "Посетите Dojo", затем следуйте серии сериалов NInject по GitHub.
Марк Seemann написал и отличную книгу о DI (Dependency Injection), которая является подмножеством МОК. Он также сравнивает несколько контейнеров. Я не могу рекомендовать эту книгу достаточно. Название книги: "Инъекция зависимостей в .Net" https://www.manning.com/books/dependency-injection-in-dot-net
Я думаю, что IoC - это шаг в правильном направлении на пути к большей производительности и удовольствию команды разработчиков (включая PM, BA a BOs). Это помогает установить разделение проблем между разработчиками и тестирование. Это дает душевное спокойствие, когда архитектура и архитектура, которая обеспечивает гибкость в качестве фреймворков, могут входить и выходить.
Лучший способ достичь цели, которую IoC (CW или Ninject и т.д.) берет на себя, - это устранение политики № 1 и № 2, чтобы разработчики не пытались создавать фасад ложного понимания при разработке. Не связаны ли эти два решения с IoC? Это:)
Вы можете ссылаться на ссылку .
Надеюсь, это поможет вам.