温莎城堡有什么缺点吗？

时间：2008-12-23 07:26:08

标签： .net asp.net dependency-injection inversion-of-control castle-windsor

我一直在研究Castle项目，特别是Windsor。我对这项技术的可能性印象深刻，拥有这种松散耦合系统的好处显而易见。我唯一不确定的是，如果使用这种方法有任何缺点，特别是在asp.net？例如性能命中等。

我正在努力让这种方法的好处在这里对我的开发人员可见，并且受到以下回击的打击：

  1. 即使用反射，每次从容器调用对象时，必须使用反射，因此性能会很差。 （这是这种情况吗？它是否在每次通话时使用反射？）

  2. 如果我依赖于接口;如何处理具有已添加到类中的额外方法和属性的对象？ （通过继承）

7 个答案:

答案 0 :(得分：34)

回答你的问题：

  
      
  1. 那是使用反射和每个   从中调用对象的时间   容器，必须使用反射   表现会很糟糕。 （这是   案子？它是否使用反射   每次通话？）
    2.   
  • 不，它没有。大多数情况下，当您注册组件时，它会使用很少的反射。在第一次从容器中请求组件时，它也可能在生成代理类型时使用反射。
  
      
  1. 如果我依赖接口;怎么样   我处理有额外的对象   已有的方法和属性   加入课堂？ （通过   继承）
    2.   
  • 这完全是设计问题。您不希望容器创建每个对象。您主要将其用于服务依赖性。在这种情况下，你不关心实际隐藏在界面后面的类型（这就是它的全部意义，不是吗？）。

您也可以拥有类组件，但它们有局限性，您必须了解这些组件（例如，您无法拦截对非虚方法的调用）。我发现温莎是最成熟的，最适合我所有的开发容器。

除此之外，Performance，我还没有听说过由于性能不可接受而不得不丢弃依赖容器的项目。温莎非常聪明，它可以缓解冗长操作的结果，因此您无需支付两倍的价格。 您可以在Internet上找到图表，比较许多IoC容器的速度。有两点需要注意：所有容器都非常快。 不要认为其他容器在这些图表上比Windsor更快的事实意味着它们更好。温莎为你做了很多其他容器没有的东西。

答案 1 :(得分：21)

我在高负载下的几个生产应用程序中使用了IoC容器（Spring.NET和StructureMap）（不是Facebook / MySpace高，但足以强调一些服务器）。

根据我的经验，甚至在我开始使用IoC之前，最大的关注点是数据库和与数据库的交互 - 优化查询，索引，使用二级缓存等。

如果您的应用程序涉及数据库，那么与数据库往返相比，Windsor或任何其他容器可能导致的任何性能都会非常小。

这就像人们在1-10ms时比较new（）运算符与Activator.CreateInstance（）的性能命中率，而单个DB往返通常要贵一个数量级。

我建议你不要担心这些小东西，而要专注于那些大事。

另外，我建议你看看StructureMap，因为我相信它比Windsor有更多的功能，并且没有很多Windsor的缺点（即坚持引用并要求你释放它们等等。）

答案 2 :(得分：10)

Castle Windsor遇到的一个问题是它无法在Medium Trust中运行（没有重新编译，我无法做到）。所以我需要从Windsor切换到Unity。

根据DI / IoC的性能 - 我相信性能影响并不大，特别是当你记住它的功能时。

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

答案 3 :(得分：7)

显着的启动成本，在操作期间几乎没有性能损失（当然没有反映调用 - 在实例化期间编译的所有内容）。温莎有点偏重，但适当的终身管理不应该造成任何问题。

更重要的缺点是在构建过程中没有捕获到集成问题，有些甚至在发布时都没有。如果不仔细跟踪所有模块的版本并对整个系统进行连续测试，很容易遇到麻烦。反思对此有所帮助，因此Windsor在这方面比其他许多DI框架更好。

答案 4 :(得分：4)

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

由于许多winforms组件的行为方式，特别是在设计时，解决组件的成本在物理上会导致鼠标在拖动时“断断续续”，因为框架可以在一秒钟内进行超过30,000次服务分辨率调用 - 这更多地反映了组件本身的不良编码实践，尽管我认为，或者至少是由于对服务提供商实现快速/简单的假设。

在实践中，即使是负载很重的商业应用程序，我也从未发现组件解析时间成为问题。

答案 5 :(得分：2)

关于表现，请参阅以下文章：

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

答案 6 :(得分：0)

  
      
  1. 即使用反射，每次从容器调用对象时，必须使用反射，因此性能将会提高   可怕。 （这是这种情况吗？它是否在每次通话时使用反射？）
    2.   

据了解所有好容器（此处包含Castle Windsor），请使用反射来创建新实例。然而，这是改善性能。这是与Activator.CreateInstance比较慢得多。 其他一些容器虽然速度很快，但可以与新的运营商竞争。见比较基准here。温莎城堡不是高性能的，但速度并不重要。说到IoC在应用程序中的使用。 90％的课程应该设置为单身，这意味着只在你的应用程序启动时工作。

  
      
  1. 如果我依赖接口;如何处理具有已添加到类中的额外方法和属性的对象？   （通过继承）
    2.   

试试这个tutorial和this教程。它将揭示您的问题的答案。如果您想避免设计问题和易于维护的软件，我强烈建议您选择SOLID practices

相关问题
最新问题