现有数据库上的AspNet Identity ApplicationDbContext

Question

我有一个包含应用程序表的现有数据库，我将使用MVC5为我的应用程序构建一个新版本。我决定将AspNet Identity框架作为应用程序的一部分。

我在创建项目时使用的visual studio模板添加了一个文件"IdentityModel.cs"和类

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
public ApplicationDbContext()
: base("DefaultConnection", throwIfV1Schema: false)
{
}
}

因此，我可以使用以下代码访问表Users、Roles和其他AspNet Identity表：

var context = new ApplicationDbContext();
context.Users.ToList();

由于Microsoft给类命名为">ApplicationDbContext"(而不是：例如，IdentityDbContext)，我想知道该类是否应该用作与AspNet Identity框架无关的所有现有表的"访问器"？

如果没有类的通用名称"ApplicationDbContext"，我只会使用我刚刚添加到解决方案中的实体框架项目来访问我的应用程序的其他表，但我想知道什么是"最佳实践"。要使用相同的AspNet Identity ApplicationDbContext访问器(以及如何使用？)或使用两个Db访问器，一个AspNet标识表，另一个用于我为其余表创建的实体框架(Db First)。

对于所有表、AspNet标识和我在一个单独的EntityFramework edmx文件中拥有的所有其他表，使用相同的dbContext看起来更符合逻辑。如何在一个dbContext中同时使用它们？

Answer 1

AspNet Identity提供了类似于用户管理器的东西，它应该可以解决您的问题。您不需要对真实的表进行操作，AspNet Identity应该涵盖表结构，并且应该允许进行高级操作。您的用户模型应该继承IdentityModel类，然后您就可以构建自己的自定义模型。

Answer 2

听起来问题的一部分是，当IdentityFramework使用代码优先实体框架时，您的应用程序的其余部分并没有使用代码优先，而是使用旧的edmx设计器方法。我不会试图将两者混合到一个单独的上下文中。

此外，因为ApplicationDbContext继承自IdentityDbContext，所以我不考虑它。基类实现了OnModelCreating和ValidateEntity之类的东西。如果您想为IdentityFramework使用其他上下文，您需要让其他上下文从IdentityDbContext继承——这是一个糟糕的语义，因为它实际上不仅仅是一个身份上下文——或者您需要手动实现这些方法。

但是，将标识框架上下文指向与其他实体框架项相同的数据库是很容易的。只需将ApplicationDbContext中的"DefaultConnection"替换为您用于其他内容的连接字符串的名称即可。