EF Core跟踪大量对象时SaveChangesAsync性能缓慢的解决方案咨询

问题背景 #

在WinForms项目中使用Grid控件进行数据查看与更新时，单个对象执行SaveChangesAsync()耗时长达3秒，需在坚持DDD原则的前提下解决该性能问题。

各方案分析 #

1. 局部改用CRUD方案 #

仅在此模块改用CRUD、其余部分保留DDD的做法并不合适：

• 会破坏领域模型封装性：ProductRecipe作为Product聚合的组成部分，绕开聚合根直接操作违反DDD聚合设计原则。
• 引发团队认知混乱：同一项目混合两种完全不同的设计思路，会提升维护成本，增加其他开发者的理解负担。
• 即使拆分到不同限界上下文，也需先评估业务合理性：若ProductRecipe的业务逻辑仍与Product强绑定，强行拆分反而会引入上下文间的集成复杂度，得不偿失。

2. 启用AsNoTracking() #

该方案在此场景下不可行：

• 由于ProductRecipe需通过聚合根Product访问，启用AsNoTracking()后EF Core不会跟踪实体状态，后续更新需手动附加实体并维护状态，反而会增加复杂度，且无法解决跟踪双实体带来的性能开销。

3. 将ProductRecipe设为独立聚合根 #

这是符合DDD原则且能解决性能问题的最佳方案，但需先验证业务合理性：

• 先确认业务规则：若ProductRecipe的更新、查询操作可独立完成（比如仅调整配方组件，无需关联Product的其他业务逻辑），那么将其设为独立聚合根完全合理。
• 调整后，可直接操作ProductRecipe聚合根，无需加载整个Product聚合，EF Core仅跟踪单个实体，能大幅降低SaveChangesAsync()的耗时。
• 若业务上需保留与Product的关联，可通过ID引用而非对象引用的方式维护，既遵循DDD原则，又避免加载冗余聚合内容。

额外优化建议 #

• 检查EF Core查询逻辑：确保更新前仅加载必要的ProductRecipe数据，避免加载Product聚合的冗余关联内容。
• 启用EF Core日志功能，查看SaveChangesAsync()执行时的SQL语句，排查是否存在不必要的批量操作或关联查询，针对性优化。

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