我是一名长期的Windows开发人员，在win32和早期的COM上已经开始了。我从2001年开始使用.Net，因此我对C＃和CLR非常流利。在我开始参与Stack Overflow之前，我从未听说过Castle Windsor。我已经阅读了Castle Windsor“入门”指南，但它没有点击。
教这个老狗的新技巧，并告诉我为什么我应该将Castle Windsor整合到我的企业应用程序中。
答案 0 :(得分：349)
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代码编写更少的缺陷。
答案 1 :(得分：3)
我认为IoC是朝着正确方向发展的垫脚石，可以提高开发团队的生产力和享受（包括PM，BA和BO）。它有助于在开发人员和测试之间建立关注点分离。当架构允许灵活性时，它可以让您高枕无忧，因为框架可能会进出。
实现IoC（CW或Ninject等）的目标的最佳方法是消除政治＃1和＃2，消除开发人员在开发时对虚假理解的需求。这两种解决方案似乎与IoC无关吗？他们是：）
答案 2 :(得分：3)
Mark Seemann撰写了关于DI（依赖注入）的优秀书籍，这是IOC的一个子集。他还比较了许多容器。我不能推荐这本书。这本书的名字是：“.Net中的依赖注入”https://www.manning.com/books/dependency-injection-in-dot-net
答案 3 :(得分：1)
Castle Windsor是Dependency Injection container.这意味着借助于此，您可以注入您的依赖项并使用它们，而无需借助new关键字创建它们。
例如考虑到您已经编写了存储库或服务，并且您希望在许多地方使用它，您需要首先注册您的服务/存储库，并且可以在将其注入所需位置后开始使用它。
你可以看一下我学习城堡温莎的下面的教程。
希望它会对你有所帮助。
答案 4 :(得分：0)
简单地输入。想象一下，您的代码中埋藏了一些类，该类需要一些简单的配置值来完成其工作。这意味着创建该类实例的所有内容都需要获得这些依赖关系，因此，您通常最终不得不重构类的负载，以仅将一些配置传递给实例的创建位置。
因此，不必要地更改了许多类，您可以将配置值捆绑到一个大的配置类中，这也很糟糕……或者更糟糕的是，还是要使用服务定位器！
IoC允许您的类轻松获得所有依赖关系，并且还可以更明确地管理实例的生存期。