ASP.NET Core Razor Pages开发中不使用模型直连数据库是否错误？

这种思路不是完全不可行，但照搬团队过去在Web Forms里的老实现逻辑，在Razor Pages开发中属于存在明显硬伤的做法——既没有发挥Razor Pages的技术优势，还带着老写法本身的固有问题。

你给出的参考代码，本身就存在跨技术栈的通用缺陷 #

这些问题和是否用Razor Pages无关，哪怕放在原来的Web Forms项目里，这种写法也算不上合格的实现：

• 存在直接的SQL注入风险：用string.Format把外部传入的ID_Cliente直接拼进SQL语句，只要这个参数被用户输入可控，就能构造注入语句拖库，这是数据库交互的核心红线问题。哪怕坚持写原生SQL，也必须改用MySqlParameter做参数化查询，绝对不能直接拼接字符串生成SQL。
• 资源释放逻辑冗余：外层已经用using块包裹MySqlConnection，这个语法本身就会在代码块结束时自动调用Dispose释放数据库连接，在finally块里手动写con.Close()、con.Dispose()属于完全重复的逻辑，还容易因为忘记关闭MySqlDataReader导致连接池泄露。
• 类型转换存在容错漏洞：直接把DataReader读出的字段值.ToString()再强转成Int32，只要数据库对应字段为NULL，就会直接抛出空引用异常，没有任何兜底处理。

澄清Razor Pages对数据访问方式的实际约束 #

很多刚接触Razor Pages的开发者会被教程误导，觉得必须搭配EF Core、必须定义实体类，实际上：

• Razor Pages只是面向页面的编程模型，本身完全不强制数据访问层的实现形式。它和后台数据库交互逻辑是完全解耦的，哪怕坚持只用原生ADO.NET连接MySQL，只要实现规范，就不存在架构层面的问题。对于小体量的内部工具、一次性的临时功能页面，这种轻量直连方式甚至比引入ORM框架更高效。
• 但“不定义模型类、直接把读取到的值存在零散变量里”的习惯，会完全浪费Razor Pages的核心优势。Razor Pages本身靠强类型的PageModel提供编译期检查、智能提示能力，你只需要花几十秒写个和查询表结构匹配的简单POCO类，把从DataReader读到的值映射到类实例上——既不需要引入任何ORM，也能解决页面端没有类型提示、字段改名无法被编译检查发现的问题，可维护性比零散存变量高得多。

明确适用边界 #

• 合理的沿用场景：你正在做老Web Forms项目的Razor Pages迁移，团队已经沉淀了大量成熟的原生SQL数据访问逻辑，没有必要投入额外精力重写成ORM模式，那只要把原有代码里的拼SQL、资源释放、类型转换的硬伤修正，完全可以继续沿用，不存在“用Razor就必须推翻所有老代码”的硬性要求。
• 不合理的使用场景：开发全新项目时，还是照着老习惯写拼接字符串的SQL、不做任何类型封装、把查询结果散落在各个零散变量里，这种写法不管放在哪个技术栈下，都属于不合格的开发实践。

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