C# 什么是温莎城堡，我为什么要关心？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/124871/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What is Castle Windsor, and why should I care?
提问by David Hill
I'm a long-time Windows developer, having cut my teeth on win32 and early COM. I've been working with .NET since 2001, so I'm pretty fluent in C# and the CLR. I'd never heard of Castle Windsor until I started participating in Stack Overflow. I've read the Castle Windsor "Getting Started" guide, but it's not clicking.
我是一名长期的 Windows 开发人员，在 win32 和早期的 COM 上崭露头角。我从 2001 年就开始使用 .NET，所以我非常流利地使用 C# 和 CLR。在我开始参与 Stack Overflow 之前，我从未听说过 Castle Windsor。我已经阅读了 Castle Windsor 的“入门”指南，但没有点击。
Teach this old dog new tricks, and tell me why I should be integrating Castle Windsor into my enterprise apps.
教这条老狗新的技巧，并告诉我为什么我应该将 Castle Windsor 集成到我的企业应用程序中。
采纳答案by Matt Hinze
Castle Windsor is an inversion of control tool. There are others like it.
Castle Windsor 是一种控制反转工具。还有其他人喜欢它。
It can give you objects with pre-built and pre-wired dependencies right in there. An entire object graph created via reflection and configuration rather than the "new" operator.
它可以为您提供具有预先构建和预先连接的依赖项的对象。 通过反射和配置而不是“new”操作符创建的整个对象图。
Start here: http://tech.groups.yahoo.com/group/altdotnet/message/10434
从这里开始：http: //tech.groups.yahoo.com/group/altdotnet/message/10434
Imagine you have an email sending class. EmailSender. Imagine you have another class WorkflowStepper. Inside WorkflowStepper you need to use EmailSender.
想象一下，您有一个电子邮件发送课程。电子邮件发件人。假设您有另一个类 WorkflowStepper。在 WorkflowStepper 中，您需要使用 EmailSender。
You could always say new EmailSender().Send(emailMessage);
你总可以说 new EmailSender().Send(emailMessage);
but that - the use of new- creates a TIGHT COUPLING that is hard to change. (this is a tiny contrived example after all)
但这 - 使用new- 创建了一个难以改变的紧密耦合。（毕竟这是一个很小的人为例子）
So what if, instead of newing this bad boy up inside WorkflowStepper, you just passed it into the constructor?
那么，如果不是在 WorkflowStepper 中更新这个坏男孩，而是将它传递给构造函数呢？
So then whoever called it had to new up the EmailSender.
因此，无论谁调用它，都必须更新 EmailSender。
new WorkflowStepper(emailSender).Step()
new WorkflowStepper(emailSender).Step()
Imagine you have hundreds of these little classes that only have one responsibility (google SRP).. and you use a few of them in WorkflowStepper:
想象一下，您有数百个这些只有一个职责的小类（google SRP）……并且您在 WorkflowStepper 中使用了其中的一些：
new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()
new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()
Imagine not worrying about the details of EmailSenderwhen you are writing WorkflowStepperor AlertRegistry
想象一下，不用担心EmailSender写作时的细节WorkflowStepper或AlertRegistry
You just worry about the concern you are working with.
你只是担心你正在处理的问题。
Imagine this whole graph (tree) of objects and dependencies gets wired up at RUN TIME, so that when you do this:
想象一下整个对象和依赖关系图（树）在运行时连接起来，所以当你这样做时：
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
you get a real deal WorkflowStepperwith all the dependencies automatically filled in where you need them.
您可以真正处理WorkflowStepper所有自动填充的依赖项。
There is no new
没有 new
It just happens- because it knows what needs what.
它只是发生了- 因为它知道什么需要什么。
And you can write fewer defects with better designed, DRY code in a testable and repeatable way.
您可以以可测试和可重复的方式使用设计更好的 DRY 代码编写更少的缺陷。
回答by Mike Socha III
I think IoC is a stepping stone in the right direction on the path towards greater productivity and enjoyment of development team (including PM, BA an BOs). It helps to establish a separation of concerns between developers and for testing. It gives peace of mind when architecting which allows for flexibility as frameworks may come in and out.
我认为 IoC 是朝着更高生产力和开发团队（包括 PM、BA 和 BO）更高生产力和乐趣的道路上正确方向的垫脚石。它有助于在开发人员和测试之间建立关注点的分离。它在架构时让您高枕无忧，因为框架可能进出，因此具有灵活性。
The best way to accomplish the goal that IoC (CW or Ninject etc..) takes a stab at is to eliminate politics #1 and #2 remove need for developers to put on the facade of false understanding when developing. Do these two solutions not seem related to IoC? They are :)
实现 IoC（CW 或 Ninject 等）所尝试的目标的最佳方法是消除政治 #1 和 #2，从而消除开发人员在开发时假装理解错误的需要。这两个解决方案似乎与 IoC 无关？他们是 ：）
回答by IUnknown
Mark Seemann wrote and excellent book on DI (Dependency Injection) which is a subset of IOC. He also compares a number of containers. I cannot recommend this book enough. The book's name is: "Dependency Injection in .Net" https://www.manning.com/books/dependency-injection-in-dot-net
Mark Seemann 写了一本关于 DI（依赖注入）的优秀书籍，DI（依赖注入）是 IOC 的一个子集。他还比较了许多容器。我不能完全推荐这本书。书名是：《.Net中的依赖注入》https://www.manning.com/books/dependency-injection-in-dot-net
回答by Rakesh Burbure
Castle Windsor is Dependency Injection container.It means with the help of this you can inject your dependencies and use them without creating them with the help of new keyword.
e.g. Consider you have written a repository or a service and you wish to use it at many places, you need to first register your service / repository and you can start using it after injecting it on the required place.
You can take a look at the below tutorial which I followed to learn castle windsor.
Castle Windsor isDependency Injection container.这意味着在此帮助下，您可以注入依赖项并使用它们，而无需借助 new 关键字创建它们。例如，假设您已经编写了一个存储库或服务，并且希望在许多地方使用它，您需要先注册您的服务/存储库，然后在需要的地方注入它后才能开始使用它。你可以看看下面的教程，我跟着它学习了温莎城堡。
link.
链接。
Hope it will help you.
希望它会帮助你。
回答by andrew pate
Put simply. Imagine you have some class buried in your code that needs a few simple config values to do its job. That means everything that creates an instance of that class needs to get those dependencies, so you usually end up having to refactor loads of classes along the way to just pass a bit of config down to where the instance gets created.
简单地说。想象一下，您的代码中隐藏了一些类，需要一些简单的配置值来完成其工作。这意味着创建该类实例的所有内容都需要获取这些依赖项，因此您通常最终不得不在此过程中重构大量类，以便将一些配置传递到创建实例的位置。
So either lots of classes are needlessly altered, you bunch the config values into one big config class which is also bad... or worst still go Service Locator!
因此，要么大量的类被不必要地改变，要么将配置值集中到一个大的配置类中，这也很糟糕……或者最糟糕的是仍然使用服务定位器！
IoC allows your class to get all its depencencies without that hassle, and manages lifetimes of instances more explicitly too.
IoC 允许您的类轻松获得所有相关性，并且也更明确地管理实例的生命周期。
