caSTLe-windsor - IoC容器适用性/场景演示？

Question

.NET 领域的很多人都选择了 CaSTLe Windsor 并在他们的项目中实现它，在过去的一年里，我一直在努力弄清楚为什么 IoC 容器似乎被视为一般的“最佳实践” “？我已经阅读了很多关于温莎之类的原因的摘要和简要解释，但其中每一个都确实是抽象的，并且对于我接触过的大多数项目来说似乎并不实用，但最近我一直在遇到很多使用 Windsor 的项目，但我不明白为什么。

C#/.NET 本质上支持基于接口(interface)的编码、抽象对象、委托(delegate)和事件。可以直接从核心语言实现 IoC，并使用 Reflection 等实例化实现已知接口(interface)的未知实例，而无需求助于 IoC 容器库。

当应用 YAGNI/AYGNI(你需要它吗？)时，我觉得温莎被过度使用了。我当然可以看到 IoC 容器的好处，但我觉得这些好处是以额外的依赖项和元数据为代价的(核心代码中调用的 IoC 容器特定属性和方法，到处都是的 .config 文件，app.config/web.config充满了绑定(bind)标签，使 .config 文件更难编辑，等等)所以我试图找出权衡。

也就是说，我接受了这样一种可能性，即我所有这些观察/陈述都是无知的，因为我从未深入参与过使用 Windsor 或其他 IoC 容器的项目图书馆。我真正需要的是让某人展示一个使用 IoC 容器库的“普通”或“典型”项目，以及为什么这应该是一个“最佳实践”，但对我来说这似乎让一个原本干净的项目变得困惑具有依赖性和元数据。

如果有人知道有任何博客文章、文章或书籍可以满足我的需求，那就太好了。

(我不是为了争论而争论，而是因为我真的很想知道我是否应该自学 IoC 容器)。

Answer 1

您似乎想要 this question 的答案

显然，如果系统像您所说的那样难以设置，那么当您开始维护它时，它的值(value)就不大了。在使用新技术时，请牢记这一点。有时，正是因为这个因素，陈旧无聊的东西变得更好。

CaSTLe Windsor 本身使用反射，因此它实际上是一个包装器，可以按照您想要的方式做事。如果您可以开发一个比 CW 更易于使用的系统，那么您应该这样做，即使这会花费您的初始启动时间。该成本首先会被 CW 的学习曲线抵消，因此它不会像重新发明轮子那样。

他们做 say themselves IoC 不适合小项目，

Also, depending on the size and complexity of the project, an IoC container might be overkill. Prefer to use it on medium to large projects.