使用EF Core结合Unit of Work模式时，大工作单元是否会降低性能？

首先明确：EF Core的DbContext本身就是Unit of Work模式的实现，当你调用SaveChanges()或SaveChangesAsync()时，EF Core会将当前工作单元内所有跟踪的变更（不管涉及多少实体），通过单次数据库往返提交到数据库，而非每个实体单独触发一次往返。

为什么不会产生多次数据库往返？ #

• EF Core会先收集所有待执行的变更（新增、更新、删除），生成对应的SQL语句，然后在同一个数据库连接中一次性执行这些SQL。比如你修改了3-4个不同实体的记录，EF Core会生成3-4条UPDATE语句，但这些语句会在同一个数据库会话中连续执行，只需要一次网络往返。
• 只有当你在工作单元流程中多次手动调用SaveChanges()，才会触发多次往返，但这违背了Unit of Work的设计初衷——应该在所有变更操作完成后，统一提交一次。

3-4个实体的场景会不会导致性能下降？ #

• 对于3-4个实体的常规操作（新增/修改/删除单条或少量记录），几乎不会出现可感知的性能问题。数据库执行几条简单SQL的开销远低于网络往返的开销，而EF Core已经把往返次数压缩到了1次。
• 只有当处理成百上千条大规模数据时，才需要考虑批量操作优化，但3-4个实体的场景完全不需要担心。

额外注意事项 #

• 尽量只跟踪需要变更的实体，避免加载不必要的数据，这能减少EF Core的内存跟踪开销，但和数据库往返无关。
• EF Core的SaveChanges()默认会开启事务，确保所有变更要么全部成功要么全部回滚，这是Unit of Work的核心特性，常规单库场景下不会因为多实体操作增加额外性能负担。

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