【问题标题】:In Unity, when are dependencies determined through reflection?在 Unity 中,依赖关系何时通过反射确定?
【发布时间】:2012-02-26 10:21:14
【问题描述】:

除了已注册的依赖项之外,是否还有通过反射确定的依赖项,例如注入的依赖项,是在依赖项的生命周期内还是在 DI 容器的生命周期内完成的?

编辑:DI Container 是 Unity。

编辑:详细说明:我很好奇反射过程发生了多少次,并且还希望清楚地了解天气或使用反射的 Unity 构建中的阶段是否会找到构造函数和属性。根据 MSDN (Source),Unity 构建的第四阶段是“Precreation”,即“第四阶段。在这里执行对构造函数、属性等的反射”。这个阶段跑了多少次?一次在容器的构建过程中,还是每次都需要解决构造函数和属性依赖关系?这发生在 Register Resolve Release 模式的哪个部分?

【问题讨论】:

  • 每个 DI 容器以不同的方式工作。你有什么特别的想法吗?
  • 是的,我一直在使用的 DI Container 是 Unity。我编辑了问题以反映这一点。
  • 我不清楚这里到底要问什么。你能详细说明吗?或许包括您提出问题的原因?
  • @MarkSeemann - 我经过精心编辑,希望能澄清问题。
  • 我想知道为什么你想知道这个?

标签: .net reflection dependency-injection dependencies unity-container


【解决方案1】:

Unity 使用名为StrategyChain 的构建管道来创建对象。每次您从容器中解析对象时都会运行此管道。

该管道中的每个步骤都作为一种策略来实施。这些策略查找值称为BuilderPolicies。这些策略封装了策略积累的信息(例如使用反射来确定要使用的构造函数、要注入的属性等)。第一次为特定类型运行管道时,策略会将策略放入名为 PolicyList 的存储中。下次要求管道构建该类型时,这些值将被重用,因此所涉及的工作只需要您花费一次。


更新

我猜你的意思是 ASP.NET?实际上有两个PolicyLists。一种只在StrategyChain(瞬态)中存在一个周期,另一种与容器的生命周期相耦合。只要您的 UnityContainer 实例没有被处理或垃圾收集,它就会一直存在。您可能会感兴趣的一件事:您不能序列化您的容器。因此,您无法告诉在网络场上运行的应用程序将其存储在缓存中并在服务器之间共享。

【讨论】:

  • PolicyList 的生命周期是多久?在.net的场景下,是按会话吗?
  • 感谢您的更新,非常感谢。假设每个已解析的对象都立即释放(让使用时间接近 0 毫秒)。解析和释放一个对象 100 次只会使用反射来确定管道一次(只要容器没有被垃圾收集)?
  • @TravisJ 如果您的对象注册了一个瞬态/每次解析生命周期,它们将被解析、使用,然后像任何其他 CLR 对象一样被垃圾收集。如果它们以单例生命周期注册,则该单个实例将被重用,因此不会被收集。在第一次解析之后,容器应该不需要再次使用反射。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-05-12
  • 2011-06-14
  • 1970-01-01
  • 2014-11-20
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多