UnitOfWork模式下多DbContext关联Identity时EF Include操作报错

报错根本原因 #

你遇到的表达式非法报错，核心原因是EF Core的Include方法仅支持识别同一DbContext范围内配置了正式关系映射的导航属性。
目前你在业务DbContext管理的News实体上，只是单纯引用了属于独立IdentityDatabaseContext的User类作为属性，既没有在业务DbContext的模型构建逻辑中为这个属性配置实体关系，两个独立的DbContext本身也不存在共享的实体追踪上下文，EF Core根本不认为这是一个合法的导航属性，自然会抛出“表达式不代表合法属性访问”的错误。
而且强行把两个独立DbContext的实体关系打通，也会直接破坏你最初的设计目标——业务DbContext对外隐藏、Identity上下文独立提供认证能力的分层边界。

适配现有分层的实现方案 #

• 内存拆分组装方案（最贴合当前UnitOfWork架构）
  完全不打破两个DbContext的隔离边界，分三步完成关联：
  1. 通过业务DbContext查询所有目标News实体，收集这批实体关联的CreateUserId外键集合
  2. 通过公开的IdentityDatabaseContext，按照收集到的用户ID批量查询匹配的User实体
  3. 在应用内存中按照ID做匹配赋值，把对应的User对象绑定到News.CreateUser属性上
     参考实现代码：

  // 从业务仓储获取新闻列表
  var newsItems = _unitOfWork.NewsRepository.GetAll().ToList();
  // 提取所有关联的用户ID去重
  var relatedUserIds = newsItems.Select(n => n.CreateUserId).Distinct().ToList();
  // 从独立的身份上下文批量拉取用户信息
  var users = _identityDbContext.Users.Where(u => relatedUserIds.Contains(u.Id)).ToList();
  // 内存中完成关联组装
  foreach (var news in newsItems)
  {
      news.CreateUser = users.FirstOrDefault(u => u.Id == news.CreateUserId);
  }
  

• 数据库视图映射方案
  如果数据量较大觉得内存组装有性能损耗，可以在数据库层创建跨schema的关联视图，把dbo架构下的业务表和identity架构下的身份表需要关联的字段整合到一起，在业务DbContext中将这个视图映射为只读实体，直接通过查询视图获取带用户信息的新闻数据，性能和原生SQL Join完全一致，也不需要打破两个DbContext的隔离。
• 统一上下映射方案（不推荐）
  如果一定要使用Include语法实现关联，需要把两个上下文的实体都合并到同一个DbContext中完成关系配置，但这种做法会直接打破你当前UnitOfWork模式下业务上下文对外隐藏的设计目标，还会让Identity认证逻辑和业务逻辑强耦合，后续维护成本会大幅升高。

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