使用 Identity 2 和 Entity Framework 6 的 IdentityUserRoles 表上的额外列/字段答案

【问题标题】：Extra column/field on IdentityUserRoles table using Identity 2 and Entity Framework 6使用 Identity 2 和 Entity Framework 6 的 IdentityUserRoles 表上的额外列/字段
【发布时间】：2015-09-17 14:41:44
【问题描述】：

我在我的项目中使用 IdentityUser 类的自定义实现。
问题是实体框架在表 IdentityUserRoles 中添加了一个额外的列，将子类 Id 映射为约束。
我知道 EF 可能对如何映射与这个新类的关系感到困惑，我只是不知道为什么以及如何解决它。我一直在网上搜索有关此 EF 行为的信息，但尚未找到解决方案。

以下是一些总结问题的截图：

【问题讨论】：

您的目标到底是什么，一个用户/角色表需要 2 个外键，但您已经知道，实体是否在制作第三个列，即用户/角色 ID，而您不希望这样？
哦，如果不够清楚，抱歉......这个额外的列不应该存在，它似乎是EF映射的问题。我想知道如何扩展 IdentityUser 类而不在多对多表（IdentityUserRoles）中创建那个额外的字段
因此，您希望该表的主键是两个外键的组合，而不是将其他无用的列作为多对多表的 id。你不能在映射后删除它吗？这就是我所做的，但它似乎不是同一个框架，我使用 4.0
如果我只使用默认配置的 Identity，该表将只有 UserId 和 RoleId 作为主键，而不是像你说的那样无用的列。我宁愿弄清楚 EF 是如何弄乱我的映射的（或者如果我弄乱了某些东西）并正确修复它。我拒绝接受这是 EF 和 Identity 的默认行为。我正在使用 EF 6.1.3 和 Identity 2.2.1 btw
好吧，我会继续寻找答案...同时，如果您不介意，我希望看到您删除该列的替代方法。

标签： asp.net-mvc entity-framework asp.net-mvc-5 asp.net-identity asp.net-identity-2

【解决方案1】：

所以，我重新检查了我的数据库映射，我想我已经找到了解决这个问题的方法：

我的用户类映射位于另一个文件 (UsuarioMap) 中，该文件继承自 EntityTypeConfiguration，然后我将在其构造函数中指定我的配置，就像帖子中的图像一样。（恕我直言，这对代码组织更好）。现在我的 IdentityUser (Usuario) 表配置只是位于 OnModelCreating 方法中：

        modelBuilder.Entity<Usuario>().ToTable("Usuario");
        modelBuilder.Entity<Usuario>().Property(u => u.UserName).IsRequired();
        modelBuilder.Entity<Usuario>().Property(u => u.Email).IsRequired();
        modelBuilder.Entity<Usuario>().Property(u => u.PasswordHash).IsRequired();
        modelBuilder.Entity<Usuario>().Property(u => u.Nome).IsRequired();
        modelBuilder.Entity<Usuario>().Property(u => u.DataRegistro).IsRequired();
        modelBuilder.Entity<Usuario>().Property(u => u.UltimoLogin).IsOptional();
        modelBuilder.Entity<Usuario>().HasOptional(u => u.Cliente).WithMany(c => c.Usuarios);

我真的不知道为什么 Entity Framework 对这两个配置路径的看法不同，因为 modelBuilder.Configurations.Add() 的参数和 modelBuilder.Entity() 是一个 System.Data.Entity.ModelConfiguration.EntityTypeConfiguration 对象，因此从逻辑上讲，这两种方式都应该有效。

【讨论】：

是的！从逻辑上讲，它应该从一开始就起作用，Entity 永远不应该在多对多表上添加额外的 id 列......这真的很奇怪......

【解决方案2】：

无法提供完整的技术解释，但我在代码中进行了这些更改以解决问题：

public class ResultzContext : IdentityDbContext<ApplicationUser>
    {
        public ResultzContext()
            : base("ResultzConnection")
        {

        }


        static ResultzContext()
        {
            // Set the database intializer which is run once during application start
            // This seeds the database with admin user credentials and admin role
            Database.SetInitializer<ResultzContext>(new ApplicationDbInitializer());
        }

        public static ResultzContext Create()
        {
            return new ResultzContext();
        }

：：

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
            {
                modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
                base.OnModelCreating(modelBuilder);
                //modelBuilder.Entity<IdentityRole>().HasKey<string>(r => r.Id).ToTable("AspNetRoles");
//modelBuilder.Entity<IdentityUser>().ToTable("AspNetUsers");
                modelBuilder.Entity<ApplicationUser>().ToTable("AspNetUsers");
                //modelBuilder.Entity<IdentityUserLogin>().HasKey(l => new { l.UserId, l.LoginProvider, l.ProviderKey }).ToTable("AspNetUserLogins");
                //modelBuilder.Entity<IdentityUserRole>().HasKey(r => new { r.RoleId, r.UserId }).ToTable("AspNetUserRoles");
                //modelBuilder.Entity<IdentityUserClaim>().ToTable("AspNetUserClaims");

所以，一般注释掉所有内容，并从 IdentityUser 更改为 ApplicationUser。但需要补充的是，我最初有 Identity 1.0 的代码希望它可以帮助你！

【讨论】：

实际上不是完全相同的问题...我见过人们使用模型构建器映射/重命名 IdentityUser 和自定义类（在您的情况下为 ApplicationUser）。在这种情况下，EF 将其映射错误是有道理的，因为两个表的目的相同，但在我的情况下，我只映射派生类（Usuario）。对我来说似乎是一个错误。

【解决方案3】：

我发现了同样的问题。有一个更简单的解决方案。您应该在 IdentityUserRole 配置中明确定义关系。

例如：

public class UserRoleConfiguration : EntityTypeConfiguration<UserRole>
{
    public UserRoleConfiguration()
    {
        HasKey(x => new {x.UserId, x.RoleId});
        HasRequired(x => x.User).WithMany(x => x.Roles).WillCascadeOnDelete();
    }
}

【讨论】：

我完全忘记了这个问题。现在我宁愿使用香草 cookie 身份验证，然后使用身份框架。为了简单和控制我的身份验证逻辑，最好不要有这个额外的层。