EF的设计迫使开发人员继承DbContext类。一些可重用的库（例如ASP.NET Identity）通常使用相同的继承路由提供其功能，即通过提供IdentityDbContext基类。
但是，如果你有2个这样的库，那么显然这不会起作用。要求您同时从IdentityDbContext和CmsDbContext继承，这显然不可能在.NET上进行。我想要的结果是有一个application-dbcontext，它包含我的身份模块和我的cms模块的模型（我不能将它分成2个dbcontexts，因为这意味着我最终会有多个连接和事务，我的模型只能引用身份或cms实体，但不能同时引用它们。
很难相信在EF社区周围似乎没有问过这个问题，但这似乎是一个非常糟糕的ORM设计。继承只允许您进行严格的线性模块化。 （作为比较，在NHibernate中，ISession和您的Configuration是两个独立的东西，因此您可以使用发现过程从不同的不相关模块构建映射配置，而不会弄乱我的ISession，从而搞乱我的db-connection / transactions）。
所以问题是，让我们说你是一个想要将模型注册到实体框架的模块的开发者（类似于ASP.NET身份模块），你赢了想拥有一个消费应用程序必须继承的基本DbContext，因为它会阻止它们使用其他模块（例如ASP.NET身份的IdentityDbContext）。那么我的选择是什么？ 有没有办法将模型注册到DbContext类而不需要从DbContext继承？是否重写了OnModelCreating获取模型构建器访问权限的唯一方法？
答案 0 :(得分：0)
我认为你的比较完全不公平。 （虽然我是第一个承认NHibernate在许多领域击败EF的人。）
对于NHibernate，通常通过一些通用方法加载对象，在该方法中提供要加载的类型。您可以创建具有硬编码ISession（或Query<T>）属性的QueryOver<T>实施，例如......
public Query<MyUser> Users { get; set; }
...而且你有同样的问题＆＃34;您无法合并或继承两种不同的实现。
同样，可以通过仅使用context.Set<T>加载对象来使用EF。您甚至可以通过在上下文的构造函数中提供EntityTypeConfiguration类（作为列表）来注入配置（类型），将它们存储在成员变量中并将它们添加到{{1中的模型构建器中覆盖。
这些专门的上下文类，如OnModelCreating，可以让它们更适合你。它们具有硬编码的IdentityDbContext属性（以及其他属性）。您不能多次继承它们的事实不是设计缺陷。它只是一个（不可协商的）语言规范。
选择最符合您需求的那个（可能DbSet）并自己添加其他类映射。