是否应始终为Razor Page专属数据使用REST API？实践疑问

1. 直接在Razor Page内通过数据库连接获取数据是否属于不良实践？ #

是的，这属于不良实践。核心问题在于职责不单一：Razor Page的本职是处理UI渲染、用户交互逻辑，把数据库连接、数据查询这类操作直接写在页面里，会让代码变得臃肿混杂——页面既要管按钮样式、页面布局，又要操心SQL语句、数据库连接池管理，后续维护时，改个数据查询逻辑都得翻一堆UI代码，效率极低。

另外，这种写法也会导致测试难度陡增：你没法单独测试数据查询逻辑，必须启动整个页面甚至完整的Web服务才能验证，单元测试几乎无从下手。一旦数据库结构变更，所有直接写在页面里的查询代码都得挨个修改，出错概率大大提高。

2. 无复用场景下，抽象数据逻辑至独立服务/API的优势是什么？ #

哪怕当前只有这一个页面用到这些数据逻辑，抽象到独立的服务层（不一定是对外的REST API，也可以是项目内的服务类）依然有明显优势：

• 关注点彻底分离：页面只负责接收数据、渲染UI，数据逻辑全在服务层，代码边界清晰，可读性和可维护性大幅提升。
• 可测试性提升：服务层的逻辑可以单独写单元测试，不用依赖Web环境，快速验证数据查询、转换逻辑的正确性，降低回归风险。
• 扩展性预留：现在没复用需求不代表以后没有——万一哪天其他页面也需要同款数据，或者要给移动端提供数据，直接复用服务层逻辑就行，不用从零开始写。
• 统一管控能力：权限校验、事务处理、日志记录这些通用逻辑可以统一放在服务层，不用在页面里重复写，避免代码冗余。

关于REST API滥用的观点 #

你的看法完全合理。REST API的核心价值是多客户端共享数据、前后端分离解耦，比如同时支持网页、iOS/Android APP的场景，用REST API能让各客户端复用同一套数据接口。但如果只是单个Razor Page专属的数据，强行套REST API纯粹是画蛇添足：你得额外处理HTTP请求、序列化/反序列化、接口鉴权这些非必要环节，增加了系统复杂度和调试成本，完全没必要。

很多示例视频用REST API，是因为它们大多演示的是前后端分离架构，或者为了展示全栈流程，但实际开发中要根据场景选择合适的方案——Razor Page这种服务器端渲染场景，直接用后端服务层处理数据逻辑就足够了，不用硬上REST API。

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