是否需要将EF/Linq实现的业务方法中的查询转换为存储过程？

现有代码的核心问题 #

你当前的写法存在非常明显的性能缺陷：

• 典型的N+1查询问题：外层先查主表dbo_FormFields_CT的列表，循环过程中针对TEXTBOX/TEXTAREA/CALCULATEDFIELD等类型，每次都单独创建数据库上下文查询对应子表，若返回的历史记录条数较多，数据库交互次数会线性增长，接口性能会非常差。
• 无意义的上下文重复创建：整个方法内多次重复new数据库上下文实例，额外增加了连接资源开销。
• 后续扩展风险高：如果后续表单字段类型继续增加，或者历史数据量上涨，这个接口很容易成为性能瓶颈。

技术主管要求的合理性 #

这个要求是合理的，原因如下：

• 性能提升明显：这类多分支匹配不同子表的逻辑，完全可以通过SQL的CASE WHEN+多表LEFT JOIN一次性在数据库侧完成所有数据查询，只用一次数据库交互就能拿到全部结果，比你现在循环查库的写法性能高好几个量级。
• 符合团队统一规范：你们团队本身已经在推进查询逻辑转存储过程的改造，统一技术实现标准后，后续所有人维护这类逻辑的成本都会更低，不会出现不同人写的查询逻辑风格差异过大、排查问题困难的情况。
• 维护更方便：如果后续需要调整查询逻辑，直接改存储过程即可，不需要重新发布应用程序，对于这类历史查询类的需求，调整效率更高。

可选的折中方案 #

如果你实在不想改存储过程，也可以先优化现有EF写法，先解决性能问题再和主管沟通：

• 整个方法复用同一个EF上下文，先按formFieldId把所有关联子表的全部数据一次性批量查出来缓存到内存，循环的时候直接在内存匹配对应记录，完全避免循环查库的N+1问题。
• 用EF的多表左连接语法一次性把所有需要的数据查出来，再在内存做对象映射，性能也能达到接近存储过程的水平。

但如果团队已经有明确的统一规范，还是优先对齐团队标准更合适，避免后续出现更多规范冲突的问题。

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