我是一名长期的Windows开发人员，在win32和早期的COM上已经开始了。我从2001年开始使用.Net，因此我对C＃和CLR非常流利。在我开始参与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()
想象一下，你有数百个这样的小类只有一个责任（谷歌SRP）..你在WorkflowStepper中使用了一些：
new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()
想象一下，当你写EmailSender或WorkflowStepper时，不要担心AlertRegistry的细节
您只是担心您正在处理的问题。
想象一下，对象和依赖关系的整个图形（树）在运行时被连接起来，所以当你这样做时：
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
你得到一个真正的交易WorkflowStepper所有依赖项自动填写你需要它们。
new它恰好发生 - 因为它知道什么需要什么。
并且您可以以可测试且可重复的方式使用设计更好的DRY代码编写更少的缺陷。
我认为IoC是朝着正确的方向发展的垫脚石，可以提高开发团队的生产力和享受（包括PM，BA和BO）。它有助于在开发人员和测试之间建立关注点分离。在架构时，它可以让您高枕无忧，因为框架可能会进出，因此可以提供灵活性。
实现IoC（CW或Ninject等）的目标的最佳方法是消除政治＃1和＃2，消除开发人员在开发时放置虚假理解的需要。这两种解决方案似乎与IoC无关吗？他们是 ：）
Mark Seemann写了关于DI（依赖注入）的优秀书籍，它是IOC的一个子集。他还比较了许多容器。我不能推荐这本书。这本书的名字是：“.Net中的依赖注入”https://www.manning.com/books/dependency-injection-in-dot-net
Castle Windsor是Dependency Injection container.这意味着在这个帮助下你可以注入你的依赖项并使用它们而无需在new关键字的帮助下创建它们。例如考虑到您已经编写了存储库或服务，并且您希望在许多地方使用它，您需要首先注册您的服务/存储库，并且可以在将其注入所需位置后开始使用它。你可以看一下我学习城堡温莎的下面的教程。
link。
希望它会对你有所帮助。
简单地说。想象一下，你的代码中有一些类需要一些简单的配置值来完成它的工作。这意味着创建该类实例的所有内容都需要获取这些依赖项，因此您通常最终必须重构类的加载，以便将一些配置传递到实例创建的位置。
因此，要么大量的类被不必要地改变，你将配置值聚集到一个大的配置类中，这也很糟糕......或者最糟糕的仍然是服务定位器！
IoC允许您的类无需麻烦地获取所有依赖项，并且还可以更明确地管理实例的生命周期。