两个IdentityDbContext在同一个数据库中

4 回答

• 0

  我不确定这是不是一个好习惯，但你可以使用不同的模式，例如：

  [dbo] .UserProfile和[webapi] .UserProfile

  据我所知，您正在使用ASP.NET MVC并使用Empty Project附带的默认IdentityDbContext .

  它使用CodeFirst方法在数据库上创建表 . 您只需创建所需的另一个并将其配置为使用不同的模式 .

  EDIT - Example

  注意[表（"UserProfile"，Schema = "dbo" ）]和[表（"UserProfile"，Schema = "webapi" ）]

  这样，EF会注意到您正在尝试从不同的表中获取数据 .

  [Table("UserProfile", Schema = "dbo")]
  public class UserProfile
  {
      [Key]
      [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
      public int UserId { get; set; }
      public string UserName { get; set; }
  }
  
  [Table("UserProfile", Schema = "webapi")]
  public class UserProfileWebApi
  {
      [Key]
      [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
      public int UserId { get; set; }
      public string UserName { get; set; }
  }
  

  如果您想更进一步，可以为这两个类创建一个接口 . 但同样，我不相信这是一个好习惯，你应该创建一个具有不同名称的表格以避免混淆 .

  回复于 2024-05-05T06:19:09+08:00
• 2

  您不应单独管理不同的用户上下文，因为实体可以区分由table或discriminator列分隔的类型 . 当对同一项使用两个上下文时，可以引入竞争条件，并且不再可能进行高速缓存 .

  回复于 2024-05-05T06:19:09+08:00
• 6

  既然你想维护 Single (same) Database . 我想，你不需要为同一个数据库使用两个不同的 Contexts .

  如果你保持 Two database 那么你可以使用 Two Context's . 除非另有说明，否则不必为Same DB提供两个上下文 . 坦率地说，浪费时间和工作 .

  对同一数据库使用多个上下文也不是一个好的代码实践 . 当它实时出现时可能会产生性能问题 .

  在您的情况下，您可以创建两个表并使用单个 Context . 因为当你写它有不同的属性和类型 . 我猜你也在使用Code First Approach . 我建议使用 single Context for single DB .

  回复于 2024-05-05T06:19:09+08:00
• 1

  我可以看到两个选项：

  • 让每个用户类型扩展基本用户，以便任何其他属性可以存储在该用户类型的单独表中 . 这将涉及将基本用户数据存储在两种类型用户的相同（现有）表中 . 如果两种用户类型的身份验证过程相同（用户名密码），则应执行此操作 . 这样，您只需使用控制器方法上的现有属性进行身份验证 .

  • 如果用户没有关于身份验证的公共属性/行为，那么您将需要为第二类用户实现自定义解决方案 . 这可能涉及为用户数据使用不同的模式或围绕身份验证创建自己的逻辑 . 我想在这种情况下，两种类型的用户永远不会调用相同的API方法？您可以为第二个用户类型创建自定义身份验证属性 . 我发现很难相信你需要走这条路 .

  回复于 2024-05-05T06:19:09+08:00