Blazor WASM(.NET Core托管带认证)：ApplicationUser与共享模型关联的循环依赖问题

这个循环依赖的坑在.NET Core托管的Blazor WASM项目里确实很常见，毕竟默认的Client/Server/Shared结构很容易遇到这种跨项目的模型关联需求。我给你几个实用的解决思路，你可以根据自己的业务场景来选：

1. 用EF Core Fluent API配置关系，只保留外键字段在Shared模型里 #

最直接的办法就是不在Shared的自定义模型里加ApplicationUser的导航属性，只保留外键（比如public string UserId { get; set; }），然后在Server端的DbContext里用Fluent API手动配置关系。

举个一对多的例子：

• Shared项目的模型：

public class CustomModel
{
    public int Id { get; set; }
    public string Title { get; set; }
    // 只留外键，不引用ApplicationUser
    public string UserId { get; set; }
}

• Server项目的DbContext配置：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);

    // 配置CustomModel和ApplicationUser的一对多关系
    modelBuilder.Entity<CustomModel>()
        .HasOne<ApplicationUser>()
        .WithMany() // 如果ApplicationUser需要反向导航，这里可以写u => u.CustomModels，记得在ApplicationUser里加这个集合属性
        .HasForeignKey(c => c.UserId)
        .OnDelete(DeleteBehavior.Cascade);
}

这种方式的好处是完全避免了循环依赖，Shared模型保持简洁。如果Client需要获取关联的用户信息，你可以在Server的API接口里查询时用Include加载用户数据，然后把需要的用户字段（比如用户名、ID）打包到返回给Client的Dto里就行。

2. 把ApplicationUser的公共抽象提取到Shared项目 #

如果你的CustomModel确实需要在Shared层体现和用户的关联关系，可以在Shared里定义一个接口或基类，包含用户的公共属性，然后让Server的ApplicationUser实现这个接口/继承基类。

比如：

• Shared项目里定义接口：

public interface IApplicationUser
{
    string Id { get; set; }
    string UserName { get; set; }
    string Email { get; set; }
    // 其他需要在Shared层用到的用户属性
}

• Server项目的ApplicationUser实现接口：

public class ApplicationUser : IdentityUser, IApplicationUser
{
    // 你的自定义用户字段，比如DisplayName之类的
}

• 然后Shared的CustomModel就可以引用这个接口了：

public class CustomModel
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string UserId { get; set; }
    // 引用Shared里的接口，而非Server的ApplicationUser
    public IApplicationUser User { get; set; }
}

最后在Server的DbContext里用Fluent API映射这个接口到ApplicationUser：

modelBuilder.Entity<CustomModel>()
    .HasOne<IApplicationUser>()
    .WithMany()
    .HasForeignKey(c => c.UserId)
    .HasPrincipalKey<IApplicationUser>(u => u.Id);

这种方式能保持模型的关联语义，同时避免循环依赖，但要注意不要把Server端特有的用户属性放到Shared的接口里，不然会破坏分层的原则。

3. 用DTO投影处理关联数据 #

如果你的主要需求是在Client端展示包含用户信息的自定义模型数据，那可以在Server端创建专门的DTO（数据传输对象），把CustomModel和ApplicationUser的需要字段投影到DTO里，再返回给Client。

比如：

• Server项目创建DTO：

public class CustomModelWithUserDto
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string UserId { get; set; }
    public string UserName { get; set; }
    public string UserEmail { get; set; }
}

• API接口里查询并投影：

[HttpGet]
public async Task<ActionResult<IEnumerable<CustomModelWithUserDto>>> GetAll()
{
    return await _context.CustomModels
        .Select(c => new CustomModelWithUserDto
        {
            Id = c.Id,
            Title = c.Title,
            UserId = c.UserId,
            UserName = c.User.UserName,
            UserEmail = c.User.Email
        })
        .ToListAsync();
}

这种方式的好处是完全隔离了Server端的实体模型和Client端的数据展示，Shared项目只需要定义核心的业务模型（或者甚至不用，直接用DTO？不过还是建议Shared放核心模型，DTO放Server或Client都行），彻底解决循环依赖问题。

4. 调整项目结构，把EF实体移到Server端 #

如果你的自定义模型本质上是EF Core的数据库实体，不需要在Client端直接操作，那可以考虑把这些实体从Shared项目移到Server项目里，然后在Shared里创建对应的DTO供Client和Server交互。

比如：

• Server项目存放CustomModel实体（可以直接关联ApplicationUser）：

public class CustomModel
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string UserId { get; set; }
    public ApplicationUser User { get; set; }
}

• Shared项目存放CustomModelDto：

public class CustomModelDto
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string UserId { get; set; }
    public string UserName { get; set; }
}

• Server端负责实体和DTO之间的转换，Client端只和DTO打交道。

这种结构更符合分层架构的原则，数据访问层的实体只在Server端存在，Client端只处理用于展示和交互的DTO，从根源上避免了跨项目的依赖问题。

内容的提问来源于stack exchange，提问作者user3621272