c# - Ninject:是否可以在 SingletonScope 中有父对象而在 TransientScope 中有子对象？

Question

几周来我一直在为此绞尽脑汁......我目前拥有的是:

• 一堆*Service类
• 所有这些都依赖于通过 EF 访问数据库的不同 *Repository 类
• 为了允许单元测试，DbContext 的派生被注入(inject)到存储库中。 (所以我不能使用 using 来处理上下文)

为了正确处理注入(inject)的 EF 上下文，我可以在 InRequestScope() 或简单的自定义范围 - InScope(c => new object()) 中运行我的依赖关系树 在顶层和 InParentScope() 在所有其他级别。

这两种方法都会在每个请求期间创建和处理大量对象。此外，我们讨论的是单页应用程序，因此 95% 的查询(大约 50 个)将在 2 个请求期间执行，因此 InRequestScope() 似乎不是一个好主意。此外，*Service 类不保持任何状态，因此可以是 InSingletonScope() 并将最小化对象创建量。

问题

是否可以在 InSingletonScope() 中包含父类 *Service 和 *Repository 并以某种方式注入(inject) EF DbContext 在每次访问时都会返回一个新实例的范围内，并且会使用 NInject 来支持 IDisposable？

我知道在创建对象时会注入(inject)依赖项，但这仍然可以通过某种方式进行管理吗？

Answer 1

不，这不可能。如果你仔细想想，你应该明白为什么。

单例对象将在应用程序的生命周期内存在。 InRequestScope 对象在请求的生命周期内存在。由于您的单例存储库将永远存在，并且它将保存对您的 DbContext 的引用(因为它是一个依赖项)，这意味着如果您的存储库没有某种机制来释放它，则 dbcontext 无法被垃圾回收。

即使你确实提供了这样的机制，你也必须有另一种机制来在下一个请求时重新获取一个新实例，因为不会创建一个新的单例存储库(因此它的构造函数不会被调用，因此它的依赖关系将不会被解析，因此它将无法知道新的 dbcontext)。

因此，实际上，使 InRequestScope 对象成为单例对象的依赖项将有效地使 InRequestScope 对象成为单例，否则该对象将从单例下释放出来，这可能很糟糕。

此外，我不同意你的观点，即你的存储库确实有状态。状态是 DbContext 本身。由于 Singleton 是一个应用程序范围的静态实例，您为使用您的应用程序的所有用户提供相同的实例，这意味着它也会提供相同的 DbContext，这是一个巨大的禁忌，因为您的用户会互相踩踏DbContext 状态。

同样，您的服务也是有状态的，因为它们有存储库，正如我刚才指出的那样，它有 DbContexts，它们是有状态的。

您要做的只是让您的服务、存储库和 DbContext 都在 RequestScope 中。

我不明白为什么这种方法会“在每个请求期间创建大量对象”。重点是它只为每个请求创建每个对象类型的一个实例。