Что такое замок Виндзор, и какое мне дело?
Я давний разработчик Windows, отрезав зубы на win32 и early COM. Я работаю с .Net с 2001 года, поэтому я довольно свободно владею C# и CLR. Я никогда не слышал о замке Виндзор, пока не начал участвовать в переполнении стека. Я прочитал руководство Castle Windsor "начало работы", но оно не щелкает.
научите эту старую собаку новым трюкам и скажите мне, почему я должен интегрировать Castle Windsor в свои корпоративные приложения.
4 ответов
замок Виндзор является инверсией инструмента управления. Есть и другие такие же.
он может дать вам объекты с предварительно построенными и предварительно проводными зависимостями прямо там. весь граф объектов, созданный с помощью отражения и конфигурации, а не оператора "new".
начните здесь: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
вы просто беспокоитесь о беспокойстве, с которым вы работаете.
представьте себе весь этот график (дерево) объектов и зависимостей подключается во время выполнения, так что когда вы это делаете:
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
вы получите реальную сделку WorkflowStepper со всеми зависимостями, автоматически заполненными там, где они вам нужны.
нет new
это просто происходит - потому что он знает, что к чему.
и вы можете написать меньше дефектов с лучше разработанным, сухим кодом проверяемым и повторяемым способом.
Я думаю, что МОК-это ступенька в правильном направлении на пути к большей производительности и наслаждению командой разработчиков (включая PM, BA an BOs). Это помогает создать разделение между разработчиками и для тестирования. Оно дает душевное спокойствие когда architecting которое учитывает гибкость по мере того как рамки могут прийти внутри и вне.
лучший способ достичь цели, которую IoC (CW или Ninject и т. д..) принимает удар на том, чтобы устранить политику #1 и # 2 удалить нужно, чтобы разработчики при разработке ставили на фасад ложное понимание. Не связаны ли эти два решения с МОК? Они :)
Марк Seemann написал и отличную книгу о DI (инъекции зависимостей), которая является подмножеством IOC. Он также сравнивает ряд контейнеров. Я не могу рекомендовать эту книгу достаточно. Название книги: "инъекция зависимостей в .Net"https://www.manning.com/books/dependency-injection-in-dot-net
замок Виндзор Dependency Injection container. Это означает, с помощью этого вы можете вводить зависимости и использовать их, не создавая их с помощью ключевого слова new.
например, подумайте, что вы написали репозиторий или услугу, и вы хотите использовать его во многих местах, вам нужно сначала зарегистрировать свой сервис / репозиторий, и вы можете начать использовать его после инъекции в нужное место.
Вы можете взглянуть на ниже учебник, который я следовал, чтобы узнать замок виндзор.
надеюсь, это поможет вам.