前言

​

在许多企业级系统或传统应用开发中，调用 SQL Server 存储过程（Stored Procedure, SP）是一个非常常见的做法。尤其在以数据库为中心的系统架构中，开发者习惯将大量逻辑写在数据库中，用 C# 去调用它们完成各种业务功能。

但在现代软件工程中，这种方式却常常被质疑、甚至被认为是反模式（Anti-pattern）。我们将结合架构设计、可测试性、可维护性等多个维度，分析为什么C#项目中调用“存储过程”不是最佳实践，以及哪些场景下它依然值得使用。

SQL Server 存储过程

非最佳实践的理由

❌ 一、职责分离：应用逻辑不应“藏”在数据库中

现代应用倡导清晰的分层架构（例如三层架构、DDD、Clean Architecture）。每一层都有明确职责：

• • 表示层（UI）：负责用户交互；
• • 业务逻辑层（Domain/Application）：实现业务规则；
• • 数据访问层（Infrastructure）：负责数据持久化；

将业务逻辑写入数据库中的存储过程，会让职责划分变得模糊：

• • 一部分业务规则在 C# 中；
• • 另一部分藏在数据库的 SP 中；
• • 日后维护时，你不再知道“订单审核逻辑”究竟是写在代码里，还是藏在某个 SP 里。

这不仅违背了关注点分离（Separation of Concerns）的原则，还让维护人员疲于奔命。

❌ 二、存储过程难以测试与调试

对比一下：

• • C# 方法：可以使用 xUnit、NUnit、Moq 进行精细化单元测试；
• • 存储过程：只能通过写 SQL 脚本人工测试，或者执行后看数据库结果。

存储过程属于“黑盒逻辑”：

• • 无法设置断点；
• • 无法单步调试；
• • 不能 Mock 外部依赖；
• • 写单元测试极其困难；

这对现代软件开发流程中的 自动化测试、持续集成（CI）和持续交付（CD） 是一个巨大障碍。

❌ 三、可维护性差，版本控制麻烦

一个存储过程的生命周期和源代码不是一回事：

• • C# 项目源码：用 Git 版本管理，有变更记录；
• • 存储过程：往往直接部署到数据库，甚至没人备份过修改前的版本。

很多团队缺乏对数据库对象的版本管理，一旦某人改了 SP 出错了，回滚都无从谈起。

此外，存储过程的调试和定位问题极其痛苦，没有 IntelliSense、没有类型提示、无法跳转引用，维护成本远高于普通 C# 代码。

❌ 四、数据库耦合严重，降低系统可移植性

如果业务逻辑大量依赖 T-SQL 写的存储过程，那基本和 SQL Server“绑死”了。迁移到 PostgreSQL、MySQL、Oracle？可能要重写一大堆逻辑，甚至整个系统的架构。

现代开发倾向于“尽量避免对具体技术栈的深度耦合”，ORM（如 EF Core、Dapper）正是这种趋势的体现。

❌ 五、安全与性能问题

• • 安全性问题：如果存储过程权限配置不当，可能让用户执行敏感操作；
• • SQL 注入问题：虽然 SP 能缓解注入风险，但不当拼接参数依然可能出错；
• • 性能问题：SP 执行效率并非一定高于应用层逻辑处理，尤其是在业务逻辑复杂、需要频繁变更的场景下。

那么，存储过程还能用吗？

当然能。在以下场景中使用存储过程是合理甚至推荐的：

✅ 什么时候使用存储过程是“合理”的？

1. 1. 批量数据处理
   比如大量插入、更新、数据清洗等操作，在数据库内执行效率更高。
2. 2. 已有遗留系统
   如果数据库中已有大量稳定的存储过程逻辑，不建议全部迁移，可以做适配层。
3. 3. 需要数据库级别的访问控制
   有些系统需要通过 SP 封装所有操作，外部只能调用已授权的存储过程，这是合理的安全策略。
4. 4. 执行计划重用
   SP 通常拥有缓存执行计划的能力，某些高频查询可以利用这一特性提升性能。

✅ 更推荐的替代方案

总结

“能写在代码里的逻辑，就不要藏在数据库里。”

这是很多资深架构师的共识。C# 与 SQL Server 的存储过程配合虽然很常见，但在现代架构中，更推荐将 业务逻辑回归到应用层，数据库应作为“持久化工具”而非“业务大脑”。

当然，存储过程并非“一无是处”，只要在合适的场景使用，依然可以成为你系统的利器。但滥用，则会让你的代码和数据库一同失控。