比较温莎城堡、Unity 和 StructureMap
在 Krzysztof 的声明的后续内容中，Windsor 比其他 IoC 做得更多，我想了解这些 IoC 是如何相互叠加的温莎城堡提供的优惠/额外设施。
有比较吗？有人可以帮助我了解温莎城堡相对于其他 IoC 提供的附加功能吗
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请参阅此处和此处对几个 IoC 容器进行了相当彻底的技术比较，尽管现在有些过时了（它们来自 Windsor 2.0 之前的版本）
但是，我不认为 Windsor 确实提供了任何重要功能而其他容器则没有。 温莎，StructureMap、Spring.NET 已经存在好几年了，并且已经被大量使用这些年来的项目很多，所以现在它们已经非常成熟了。较新的容器，例如 Autofac、Unity、Ninject 和 SimpleInjector 建立在以前的经验之上，因此他们也不会缺少这些重要功能。
现在是答案中更主观的部分：我喜欢认为 Windsor 很好地结合了可用性、可扩展性和集成模块。
可用性：例如，您可以使用 XML 和/或代码注册（它还有一个 流畅的 API 就像当今大多数容器一样）。
可扩展性：您可以使用很多扩展点自定义或覆盖几乎任何默认行为。
集成：温莎拥有很多设施（模块）允许与其他框架/库轻松集成。其他集成包括 ASP.NET MVC、MonoRail, 工作流基础，NServiceBus，大众交通、Rhino 服务总线、 Quartz.Net，SolrNet, SolrSharp, Windows 传真服务。
本系列文章涵盖了许多细节和扩展温莎的点。
请注意，我并不是说其他容器不提供类似的功能！即使您选择了其中之一，后来发现它缺乏一些集成，自己编写代码通常也不难。
底线：我认为只要正确构建代码（例如避免服务定位器反模式），任何主要的 IoC 容器都不会出错。
See here and here for a pretty thorough technical comparison of several IoC containers, although somewhat outdated by now (they're from before Windsor 2.0)
However, I don't think there are really any vital features that Windsor offers and other containers don't. Windsor, StructureMap, Spring.NET have all been around for several years and have been used in lots of projects over these years so they're very mature now. Newer containers, like Autofac, Unity, Ninject and SimpleInjector build on that previous experience so they won't lack those vital features either.
Now the more subjective part of the answer: I like to think that Windsor has a nice mix of usability, extensibility and integration modules.
Usability: for example, you can use XML and/or code registration (it also has a fluent API like most containers nowadays).
Extensibility: Lots of extension points that you can use to customize or override pretty much any default behavior.
Integration: Windsor has lots of facilities (modules) that allow for easy integration with other frameworks/libraries. Other integrations include ASP.NET MVC, MonoRail, Workflow Foundation, NServiceBus, MassTransit, Rhino Service Bus, Quartz.Net, SolrNet, SolrSharp, Windows Fax Services.
This series of articles covers many niceties and extension points of Windsor.
Note that I'm not saying that other containers don't offer similar things! Even if you picked one of them and later you found out it's lacking some integration, it's usually not hard to code it yourself.
Bottom line: I don't think you can go wrong with any of the main IoC containers, as long as you structure your code properly (e.g. avoid the service locator anti-pattern).
对我来说，Windsor 有两个杀手级功能，我认为大多数其他容器都没有提供。
能够以与容器无关的方式工作 - 这意味着您的容器可以为您引导所有代码，并且您可以充分利用其丰富的功能，而无需在非基础设施程序集中引用任何 Castle.*.dll 程序集。这要归功于惰性组件加载器、动态参数和类型化工厂设施等功能，这些功能不会限制您利用容器的高级功能，同时避免手动编码集成层或使用服务定位器，正如 @ploeh 所写的那样 集
非常丰富的可扩展性/扩展生态系统，可以为您提供真正强大的功能，并大大减少您必须编写的管道代码量。这听起来可能不太强大，但是一旦您在一个项目中利用了 WCF 工具等功能，您就会欣赏它，但在另一个项目中您将无法使用它。
可扩展性部分意味着虽然 Windsor 不会尝试（这是它的设计目标）解决开箱即用的每个问题，但它具有很强的可扩展性，这意味着您可以调整和扭转它来完成您可能需要的几乎任何事情。
除此之外，我只是碰巧喜欢温莎的工作方式，与预期的一样（与其他一些容器相反）以及它如何解决小问题。例如，创建装饰服务非常简单。我也非常喜欢它流畅的注册 API，它对于两种简单的场景都非常有效，并且当你想做一些高级的事情时也不会变得太扭曲和复杂。还有很多其他小事情，尽管这里的事情可能非常主观。
For me there are two killer features of Windsor that I don't believe most other containers provide.
Ability to work in a container agnostic way - this means your container can bootstrap all the code for you and you can take full advantage of its rich capabilities without ever referencing any of Castle.*.dll assemblies in your non-infrastructure assemblies. This is thanks to features such as Lazy Component Loaders, DynamicParameters and Typed Factory Facility, which do not constraint you from taking advantage of advanced capabilities of the container, while avoiding manually coding integration layer, or using Service Locator, which as @ploeh wrote is an anti pattern.
very rich extensibility/extensions ecosystem which can give you really powerful capabilities and greatly reduce amount of plumbing code you have to write. This may not sound powerful, but you will appreciate it once you take advantage of things like WCF Facility in one project, and then in another you won't be able to use it.
The extensibility part means that while Windsor does not try (this is its design goal) to solve every issue you may have out of the box, it is very extensible, which means you can tweak and twist it to do almost anything you may need.
Other than that I just happen to like the way Windsor works pretty much as expected (contrary to some other containers) and how it solves the little things. For example creating decorated services is very simple. I also like it's fluent registration API very much, which works very well for both simple scenarios, and does not get too twisted and complicated when you want to do something advanced. Plus a lot of other small things although here things can be pretty subjective.