Question

我想知道Ninject如何处理EF DbContext注入是以下情况。

有一个实用程序类将DbContext作为参数并执行一些需要dbContext的工作：

public class SomeClass : ISomeClass
{
    public SomeClass(MyDbContext context)
    {
        //the context is dependency injected
    }
}

有一个API控制器，它接受DbContext以及ISomeClass的注入实例（也需要DbContext）

    public class SomeController
    {

        public SomeController(MyDbContext context, ISomeClass someClass)
        {
            //this controller uses db context for some simple actions and someclass for some more complex actions
        }
    }

绑定选项设置为：

kernel.Bind<MyDbContext>().ToSelf().InRequestScope();

现在，问题是

当实例化SomeController时，SomeClass的实例是否共享同一个MyDbContext实例？另外，如果SomeClass注入了SomeSubClass并将MyDbContext注入到构造函数中，那么它是否是相同的上下文实例？

它是否有效：

http请求进来并需要创建控制器及其需要DbContext的依赖项，因此我们设置为 InRequestScope，让我们返回相同的实例来统治它们吗？

如果是这样，那么获取上下文并创建UnitOfWork类（pattern from here）的控制器构造函数之间没有区别（DbContext）

public class SomeController(MyDbContext context)
{
   this.someUnitOfWork = new SomeUnitOfWork(context);
}

以及将工作单位作为注入参数

的工作单元

public class SomeController(MyDbContext context, ISomeUnitOfWork someUnit){}

在这里，唯一的区别是与SomeUnitOfWork实现的紧密耦合？

Answer 1

http请求进来并需要创建控制器及其需要DbContext的依赖项，因此我们设置为在InRequestScope中，让我们返回相同的实例来统治它们吗？

是。这就是InRequestScope的作用。

https://github.com/ninject/Ninject.Web.Common/wiki/InRequestScope包含所有有趣的细节：

使用InRequestScope（）的主要原因是确保a 对象的单个实例由通过它创建的所有对象共享该HTTP请求的Ninject内核（例如，共享一个对象）创造成本高昂。）

依赖注入DbContext是否在给定请求实例中使用它的所有类之间共享？

1 个答案: