DbContext 多重继承

Question

EF 的设计迫使开发者继承 DbContext 类。一些可重用的库（例如 ASP.NET Identity）通常使用相同的继承路径提供其功能，即通过提供 IdentityDbContext 基类。

但是如果你有 2 个这样的库，这显然是行不通的，例如要求您同时从 IdentityDbContext 和 CmsDbContext 继承，这在 .NET 上显然是不可能的。我想要的结果是有一个 application-dbcontext 包含来自我的身份模块和我的 cms 模块的模型（我将无法将其分离为 2 个 dbcontexts，因为这意味着我最终将获得多个连接和交易，并且我的模型只能引用身份或 cms 实体，但不能同时引用两者）。

很难相信这个问题似乎没有在 EF 社区中被问到，但这似乎是一个非常糟糕的 ORM 设计。继承只允许您进行严格的线性模块化。 （作为比较，在 NHibernate 中，ISession 和您的配置是 2 个独立的东西，因此您可以使用发现过程从不同的不相关模块构建映射配置，而不会弄乱我的 ISession 以及我的数据库连接/事务）。

所以问题是，假设您是一个模块的开发人员，想要将模型注册到实体框架（类似于 ASP.NET 标识模块）中，您不希望有一个基础 DbContext使用应用程序必须继承，因为它会阻止它们使用其他模块（例如 ASP.NET 身份的 IdentityDbContext）。那么我的选择是什么？ 有什么方法可以将模型注册到 DbContext 类中而不需要从 DbContext 继承？覆盖 OnModelCreating 是访问 ModelBuilder 的唯一方法吗？

Answer 1

我认为你的比较并不完全公平。 （虽然我是第一个承认 NHibernate 在很多方面都胜过 EF 的人）。

使用 NHibernate，通常您通过一些通用方法加载对象，在这些方法中您提供要加载的类型。您可以使用硬编码的Query<T>（或QueryOver<T>）属性创建ISession 实现，例如...

public Query<MyUser> Users { get; set; }

...您会遇到无法合并或继承两个不同实现的相同“问题”。

同样，您可以通过仅使用 context.Set<T> 加载对象来使用 EF。您甚至可以通过在上下文的构造函数中提供EntityTypeConfiguration 类（作为列表）来注入配置（某种程度上），将它们存储在成员变量中并将它们添加到OnModelCreating 覆盖中的模型构建器中。

这些专门的上下文类，如IdentityDbContext，如果适合您，可以让生活更轻松。他们有硬编码的DbSet 属性（等等）。您不能多重继承它们的事实不是设计缺陷。这只是一个（不可协商的）语言规范。

选择最能满足您需求的一个（可能是CmsDbContext）并自己添加其他类映射。