温莎城堡国际奥委会“成本”答案

【问题标题】：Castle Windsor IoC "cost"温莎城堡国际奥委会“成本”
【发布时间】：2013-03-07 20:45:06
【问题描述】：

使用 Castle Windsor 进行依赖关系解析的性能成本在哪里？是new WindsorContainer()，还是container.Resolve<T>()？

根据对此的回答，ASP.NET 服务是否应该根据需要初始化Application_Start 中的Container，然后再初始化Resolve<T>()？或者Resolve<T>() 也在Application_Start？

顺便说一句 - 我知道这可能会在某些人的脑海中构成过早的优化...我只是在寻找可扩展 ASP.NET 服务的正确实现。

【问题讨论】：

为什么不自己测量呢？
是的 - 感谢@svick 的帮助。当我可以自己回答所有问题时，为什么还要有 StackOverflow.com？我正在寻找该领域的专家，以免我不得不在分析方面做一些糟糕的尝试。
我的意思是，你可以自己测量。你为什么要把专家的时间浪费在你可以自己做的事情上？ SO 期望您进行合理数量的研究，而在我看来，您似乎没有这样做。所以不应该是“我懒得做这个，给我做”，应该是“我不知道怎么做，你能做到吗？”
为什么要发表评论，基本上是说您不能对问题添加任何建设性内容？您对“为什么不自己回答这个问题”的回答几乎没有建设性。

标签： .net performance castle-windsor ioc-container

【解决方案1】：

大多数应用程序中最昂贵的操作是在容器中注册组件 (container.Install(FromAssembly.This()))，这是每个应用程序执行一次的操作。

解决问题，除非您做的事情确实错了，否则成本往往可以忽略不计。

扩展注册。与容器做的其他事情相比，它的成本很高。在绝对数量上，它仍然足够快，不会让绝大多数应用程序感到头疼。

因为这是容器（以 Windsor 为例，因为这就是您似乎正在使用的，而且我碰巧知道最好的）去扫描程序集（通过反射）以找到您想要的类型注册，然后检查这些类型（使用反射）以构建适当的组件模型，然后将所有这些信息提供给设施和其他扩展以进行检查和可能的修改。此时还会进行依赖图分析和各种优化，以便在注册过程完成后，Windsor 可以更快地执行其他更频繁的操作。

【讨论】：

究竟是什么让注册组件如此昂贵？
这可能是在注册一些复杂的“构造指令”时容器内部发生的反射。诸如使用反射选择构造函数、将参数映射到参数等等。这就是您在代码中没有硬编码“新”所付出的代价。