我正在学习Asp.net Core和Entity Framework Core,并使用代码优先方法创建了一个带有数据库的基本Web应用程序。我的应用程序有一个上下文(AppContext),要使用身份,我定义了一个新的上下文(IdentityContext),它使用相同的数据库。 我想将每个身份的用户(IdentityContext中的AppUser)与一个雇员(来自AppContext)相关联,但是当我尝试使用EF Core时,为其创建一个新表。
public class AppUser : IdentityUser
{
public Employee Employee { get; set; }
}
public class Employee
{
public long Id { get; set; }
public string AspNetUserId { get; set; }
public AppUser AppUser { get; set; }
}
AppContext
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Employee>(employee =>
{
employee.HasIndex(e => e.AspNetUserId);
employee
.HasOne(e => e.AppUser)
.WithOne(au => au.Employee)
.HasForeignKey<Employee>(e=>e.AspNetUserId);
});
}
我对此有很多疑问:
任何建议或参考将不胜感激。
谢谢。
答案 0 :(得分:0)
我认为可以有两个单独的上下文,每个上下文都有一个 一个关注点。可以吗还是应该将AppContext复制粘贴到 IdentityContext?
很好。问题是您想将它们分开,但不要让它们有自己的问题。
您当前正在告诉IdentityContext它应该同时具有AppUser和Employee,并且它们之间存在关系。然后,上下文将照顾到这两个对象,除非您明确要求不要这样做。但是现在您正在明确地告诉它。
几乎可以总结为以下简单规则:分离的上下文->分离的数据。
如何告知我的AppContext没有为其创建新表 AppUser,并使用由IdentityContext创建的表?
您真的不应该。不要期望实体框架能够处理上下文之间的关系。几乎不会。如果您的实体具有连接,则它们属于同一上下文。您可以将其视为不同的数据库。在两个不同的数据库之间进行查询不是那么顺利。
不过,您仍然可以通过告诉配置忽略这样的引用实体来分离它们:
modelBuilder.Entity<AppUser>().Ignore(e => e.Employee);
但是,这可能只会使您感到困惑,因为除非您亲自进行操作,否则不会跟踪或映射这些实体。因此,我建议您坚持使用ID作为参考/外键,让他们过自己的生活,或者合并它们并执行您当前的计划。如果您是游戏新手,我建议您坚持一种环境。
还有其他选择吗?
我喜欢为标识分离一个上下文的想法,因为它的某些逻辑可能与UI层相关,并且实际上很少需要对用户上其他实体的任何引用。在迁移等方面,确实需要付出额外的努力,但总的来说,它运行得很好。您仍然可以通过一些简洁的通用方法和接口轻松获取属于用户的相关实体。
但是如果我的实体少于15-20个,我什至不会这样做。只是不值得。这么小的项目带来的好处还是太少了。