代码之家  ›  专栏  ›  技术社区  ›  Blounty

温莎城堡有什么缺点吗?

  •  35
  • Blounty  · 技术社区  · 17 年前

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

    我正在努力使这种方法的好处在这里对我的开发伙伴可见,并受到以下回击的打击:

    1. 即使用反射,每次从容器调用对象时,都必须使用反射,这样性能将很差。(是这样吗?它是否在每次通话中都使用反射?)

    2. 如果我依赖接口,如何处理具有附加到类上的额外方法和属性的对象?(通过继承)

    7 回复  |  直到 7 年前
        1
  •  34
  •   Kirk Sage    7 年前

    要回答您的问题:

    1. 使用反射和 从中调用对象的时间 容器,反射必须这样使用 性能会很差。(这是 案件?它使用反射吗 每一个电话?)
    • 不,不是。大多数情况下,当您注册组件时,它使用的反射很少。它还可以在生成代理类型时使用反射,第一次从容器请求组件时。
    1. 如果我依赖接口;如何 我要处理有多余的东西吗 方法和属性 加入班级?(通过 继承性)
    • 一切都是设计问题。您不想让容器创建每个对象。它主要用于服务依赖性。在本例中,您不关心实际上隐藏在接口后面的是什么类型(这就是它的全部意义,不是吗?).

    您也可以有类组件,但它们有局限性,您必须了解这些组件(例如,您不能截获对非虚拟方法的调用)。我发现温莎是最成熟的,最适合我的发展风格的容器。

    除了性能,我还没有听说过一个项目因为性能不可接受而不得不丢弃依赖容器。温莎真的很聪明,而且它保存了长期运营的结果,这样你就不必付两倍的价格。 您可以在互联网上找到图表,比较许多IOC容器的速度。有两点需要注意:所有的容器都非常快。 不要认为其他集装箱在这些图表上比温莎更快,这意味着它们更好。温莎为你做了很多其他容器没有做的事情。

        2
  •  21
  •   chadmyers    17 年前

    我在一些高负载(不是Facebook/MySpace的高负载,但足以让一些服务器承受压力)的生产应用程序中使用了ioc容器(spring.net和structuremap)。

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

    如果你有一个数据库与你的应用程序有关,那么无论什么性能击中温莎或任何其他容器可能造成的,将是如此不完整的小相比,DB往返。

    这就像人们在1-10毫秒时比较new()运算符与activator.createInstance()的性能命中率,而单个db往返通常要比它高出一个数量级。

    我建议你不要担心小事情,集中精力做大事情。

    另外,我想建议你看看结构图,因为我相信它比温莎的功能更多,也没有很多温莎的缺点(即,坚持引用并要求你发布它们等)。

        3
  •  10
  •   gius    17 年前

    我遇到的温莎城堡的一个问题是,它不能在中等信任下运行(没有我无法完成的重新编译)。所以我需要从温莎转向团结。

    根据DI/IOC的表现,我认为性能影响不大,特别是当你记住它的力量时。

    顺便说一句:如果你从DI/IOC开始,你应该阅读 this MSDN article .

        4
  •  7
  •   ima    17 年前

    显著的启动成本,在操作过程中几乎没有性能损失(当然,没有对调用的反射——所有的都是在实例化过程中编译的)。温莎有点沉重,但有了适当的终身管理,不应该造成任何问题。

    一个更重要的缺点是,集成问题在构建过程中不会被发现,有些甚至在发布时也不会被发现。如果不仔细跟踪所有模块的版本和对整个系统的持续测试,很容易陷入麻烦。反射在这里有帮助,所以温莎在这方面比其他许多DI框架都要好。

        5
  •  4
  •   Bittercoder    17 年前

    在我的经验中,IOC容器的性能不可接受的一个例外是,当尝试将IOC容器集成/包装为用于组件模型的IServiceProvider时-这一曾经常见的例子是在创建自己的托管WinForms设计器时(通常用于构建某种自定义设计器,即工作流/流程图等)

    由于许多WinForms组件的行为方式,特别是在设计时,解析组件的成本在物理上会导致鼠标在拖动时“结巴”,因为框架每秒可以生成超过30000个服务解析调用-这更多地反映了组件本身糟糕的编码实践,尽管我思考一下,或者至少是因为对服务提供者实现的假设是快速/简单的。

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

        7
  •  0
  •   Vladimir Moushkov    10 年前
    1. 即使用反射,每次从容器调用对象时,必须使用反射,这样性能将 可怕的。(是这样吗?它是否在每次通话中都使用反射?)

    据了解,所有好的容器(包括温莎城堡)都使用反射来创建新的实例。但是,这可以提高性能。这是为了与Activator.CreateInstance进行比较,后者要慢得多。 不过,其他一些集装箱速度相当快,可以与新的运营商竞争。见比较基准 here . 温莎城堡不是高性能的,但是速度并不重要。当涉及到国际奥委会在应用中的使用时。90%的类应该以单音形式安装,这意味着只在应用程序启动时工作。

    1. 如果我依赖接口,如何处理具有附加到类上的额外方法和属性的对象? (通过继承)

    试试这个 tutorial this 教程。它会告诉你问题的答案。如果你想避免设计问题和易于维护的软件,我强烈建议你去 SOLID practices