.net 温莎城堡有什么缺点吗？

我一直在调查城堡项目，特别是温莎。我对这项技术的可行性印象深刻，拥有这样一个松散耦合系统的好处是显而易见的。我唯一不确定的是，使用这种方法是否有任何缺点，特别是在asp.net中？例如，性能命中率等

我正试图让我的开发伙伴们看到这种方法的好处，并受到以下回潮的打击：

这就是使用反射，每次从容器调用对象时，都必须使用反射，这样性能会很糟糕。（是这样吗？它是否在每次通话中都使用反射？）

如果我依赖于接口；如何处理具有附加到类上的额外方法和属性的对象？（通过继承）

---

我遇到的Castle Windsor的一个问题是，它不能以中等信任度运行（没有重新编译，我无法做到）。所以我需要从温莎转向团结

根据DI/IoC的表现——我认为，表现的影响并不大，特别是当你记住它的力量时

---

顺便说一句：如果你是从DI/IoC开始的，你应该阅读。

重要的启动成本，在操作过程中几乎没有性能损失（当然，没有对调用的反映-所有内容都是在实例化过程中编译的）。温莎是一个有点沉重的一面，但适当的终身管理应该不会造成任何问题

---

一个更重要的缺点是集成问题在构建过程中没有被发现，有些甚至在发布时也没有被发现。如果不仔细跟踪所有模块的版本，不连续测试整个系统，很容易出现故障。反射在这方面很有帮助，因此Windsor在这方面比许多其他DI框架更好。

关于性能，请参阅以下文章：

但请记住，其中一些容器有更新（可能更快）的版本，尤其是Unity。

我在几个高负载的生产应用程序中使用过IoC容器（Spring.NET和StructureMap）（不是Facebook/MySpace high，但足以让一些服务器感到压力）

根据我的经验，甚至在我开始使用IoC之前，最大的性能问题就是数据库以及与数据库的交互——优化查询、索引、使用二级缓存等等

如果你的应用程序涉及到一个数据库，那么无论Windsor或任何其他容器的性能受到什么影响，与DB往返相比都是微不足道的

这就像有人比较new（）操作符与Activator.CreateInstance（）在1-10ms时的性能影响，而单个DB往返通常要贵一个数量级

我建议你不要为小事担心，而要专注于大事

---

另外，我想建议您看看StructureMap，因为我相信它比Windsor有更多的功能，并且没有Windsor的很多缺点（即保留引用并要求您发布引用等）。

回答您的问题：

这就是使用反射和每个 从中调用对象的时间 容器，因此必须使用反射 表演会很糟糕。（这是吗 案例？它是否使用了反思 每一个电话？）

• 不，没有。大多数情况下，注册组件时，它几乎不使用反射。当您第一次从容器请求组件时，它还可以在生成代理类型时使用反射

如果我依赖于接口；怎样 我处理的对象有额外的 方法和属性，这些方法和属性 被钉在课堂上？（通过 继承权）

• 这都是设计的问题。您不希望容器创建每个对象。您主要将其用于服务依赖性。在这种情况下，您不关心接口后面实际隐藏的是什么类型（这就是它的全部意义，不是吗？）

您也可以有类组件，但它们有一些限制，您必须了解这些限制（例如，您不能拦截对非虚拟方法的调用）。我发现温莎是最成熟的，最适合我的开发风格

除此之外，性能方面，我还没有听说过一个项目因为性能不可接受而不得不放弃依赖容器。温莎在这方面真的很聪明，它将长期运营的结果缓存起来，这样你就不必付出两次代价。 你可以在互联网上找到图表，比较许多IoC容器的速度。有两点需要注意：所有的容器都非常快。

---

不要认为其他集装箱在这些图表上比温莎更快，这意味着它们更好。Windsor为您做了很多其他容器没有做的事情。

在我的经验中，IoC容器的性能不可接受的一个例外是，尝试将IoC容器集成/包装为IServiceProvider以在ComponentModel中使用-一个曾经常见的例子是在创建您自己的托管winforms设计器时（通常用于构建某种自定义设计器，即工作流/流程图等）

由于许多winforms组件的行为方式，特别是在设计时，解析组件的成本将导致鼠标“结巴”当拖动时，因为框架一秒钟可以进行30000次以上的服务解析调用——虽然我认为这更多地反映了组件本身的糟糕编码实践，或者至少是由于对服务提供商实现快速/简单的假设

在实践中，我从未发现组件解析时间在重载的商业应用程序中也是一个问题