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提供给“应用程序 DbContext”类的名称（而不是：身份 DbContext），我想知道该类是否应该用作所有其他与AspNet Identity框架无关的现有表的“访问器”是什么？

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

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

Answer 1

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

Answer 2

听起来您的问题的一部分是，虽然IdentityFramework使用code-first实体框架，但您并未使用代码优先于应用程序的其余部分，而是使用较旧的edmx设计器方法。我不会尝试将两者混合成一个上下文。

此外，由于ApplicationDbContext继承自IdentityDbContext，我会不理会。基类实现OnModelCreating和ValidateEntity之类的东西。如果你想在IdentityFramework中使用你的其他上下文，你需要让你的另一个上下文继承自IdentityDbContext - 这是一个糟糕的语义，因为它实际上只是一个身份上下文 - 或者你＆＃39;需要手动实现这些方法。

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

现有数据库上的AspNet Identity ApplicationDbContext

2 个答案: