.NET 内存分析 / 泄漏风险 / Ninject / 直接委托根答案

【问题标题】：.NET memory profiling / risks for leaks / Ninject / Direct delegate roots.NET 内存分析 / 泄漏风险 / Ninject / 直接委托根
【发布时间】：2011-07-07 07:30:43
【问题描述】：

我正在分析一个使用 Ninject 进行 DI 的应用程序。随着时间的推移，我看到了很多 BindingBuilder 类的实例，这些实例用于定义容器中定义的对象。

Ninject 的“ToMethod”绑定用于定义容器中的所有对象。 Lamba 中可用于访问内核的上下文随后用于从容器中检索其他对象。示例：

Bind<IService>()
    .ToMethod(ctx => new CustomService(
        ctx.Kernel.GetDefault<IOtherService>(), 
        ctx.Kernel.GetDefault<IAnotherService>()
    ))
    .InSingletonScope();

看到 BindingBuilders 随着时间的推移而增加是正常的行为，还是这些引用应该只存在一次？

【问题讨论】：

标签： .net asp.net debugging memory ninject

【解决方案1】：

ToMethod 在 BindingBuilder 中为 lambda 表达式创建一个新的匿名类。你看到的不是BindingBuilder 的实例，而是BindingBuilder<T>+c__DisplayClass1<IService> 之类的实例

此外，您没有按预期使用 Ninject。上面的绑定可以更容易编写。让 Ninject 决定注入什么，而不是添加显式定义。

Bind<IService>().To<CustomService>.InSingletonScope();

【讨论】：

感谢您。我们拥有它的原因是我们已经命名了我们特别想要注入的实例，因此我们可以为给定的接口定义两个具有不同名称的实现。我们如何让 Ninject 决定在这种情况下使用哪个？
这是一个完全不同的故事，取决于有多个实现的原因。这个问题的答案是否定的，BindingBuilder 没有内存泄漏。
没关系，我想不会有。您是否希望通过 BindingBuilder 路由逐渐建立匿名类？您对命名实例以及注入这些实例的最佳方法有任何指导吗？我以为我们正在使用推荐的方法，但他们可能是更好的方法？
我希望每个使用 ToMethod（或以 lambda 作为参数的任何其他方法）的绑定都有一个新匿名类的单个实例。
关于另一个问题，我成功地提出了一个新问题，其中包括为什么您有多个实例以及您想要实现的信息。例如这些不同的策略是由策略使用者的某些条件选择的，还是因为您想以不同的方式部署它，....正如我所说的，没有一种解决方案，有很多针对不同情况的解决方案。目前只是猜测。