Ninject 和 DbContext答案

【问题标题】：Ninject and DbContextNinject 和 DbContext
【发布时间】：2015-08-26 13:14:37
【问题描述】：

使用 EF 6 和 Ninject 3.2.2 构建应用程序我在思考如何以智能方式访问 DbContext 时遇到了一些麻烦。

据我了解，在 Ninject 的较新版本中，仅鼓励构造函数注入。作为 EF 6，它本身就是 repo 和工作单元，我没有在 EF 之上进行任何抽象。如果希望能够使用多个小型工作单元，那么将 DbContext (uow) 注入到每个需要它的类中是行不通的。以非 IoC 的方式，我会这样做：

Using(var db = new DbContext){}

如何使用 Ninject 实现这一点，因为我不再可以在我的 using 块中执行 kernel.get...

【问题讨论】：

EF 让您可以访问数据库。您仍然需要告诉它您希望如何在该级别提取和操作数据。出于这个原因，我认为使用 repos 和 UoWs 没有任何问题。事实上，这就是 Julie Lerman 在 Pluralsight 课程中展示的内容。
那是什么课程？我刚刚看到“EF 6 Beginner”课程，是的，se 确实使用了 repos，但她不使用 IoC，所以她没有解决我遇到的问题......
我非常高兴地观看了“企业中的实体框架”。关于 IoC 问题，一旦你有了 repos，你就可以像任何其他类一样注入它们。
感谢您的建议，我会检查该课程。回购并不是真正的问题，事实上我想要多个小单元在我的方法中......
DbContext 是框架类型；你应该not auto-wire framework types。

标签： c# entity-framework ninject inversion-of-control

【解决方案1】：

我会考虑两种方法：

创建通用DbContext，可以隐藏在界面后面：

public interface IPortalContext : IDisposable
{
    DbSet<User> Users { get; }

    DbContext Context { get; }
}

public class PortalContext : DbContext, IPortalContext
{
    public PortalContext()
        : base("PortalConnectionString")
    {
    }

    public virtual DbSet<User> Users { get; set; }
}

然后你可以毫无问题地将你的上下文注入构造函数。

创建许多可用于不同场景和类别的小型上下文。

我不认为第一种方法不好，因为它只封装了您的 DbSets 和 DbContext 使其更容易注入和测试。您不会在 EF 之上制作任何不必要的层，整个界面看起来非常透明。

无论如何，这种方法比让整个 IRepository<T> 东西访问另一个存储库要好...

【讨论】：

【解决方案2】：

我不太清楚你所说的“多个小单元作品”是什么意思，但只是为了曝光，这是我在最近的一个应用程序中所做的：

在小的有界上下文中划分域（这更像是一个概念性步骤）
每个有界上下文都有：上下文、存储库、存储库工厂
每个上下文都实现了一个 IContext 和一个 BaseContext，它们提供了基本方法和通用属性（IContext 将用于模拟）
每个存储库都将相对上下文作为构造函数参数
这是存储库工厂的示例

公共类 CartRepositoryFactory : IRepositoryFactory { 公共 IRepository 生成（CartContext ctx） { 返回新的 CartRepository(ctx); } }
在应用服务层，我注入了一个UoW和我需要的repository factory
如果我想在一个服务中使用多个不同的上下文，我只需创建另一个服务并组合我需要的服务并注入它们

你可能会问，但为什么？！？这太疯狂了！！

好吧，因为如果存储库管理 DbContext，那么每个类实例化我只能执行一个操作。这允许我打开一个 DbContext 并对存储库进行多次调用。当然现在你在应用服务层面也有同样的问题，每次实例化只能调用一个方法，但是管理起来要容易得多。

最终这一切都取决于您的喜好：您更喜欢精简服务还是精简存储库？

【讨论】：