2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
基于实践经验，对许多团队在未衡量其后果的情况下所做出的决策进行的反思。
有些技术决策几乎是自动做出的，没有经过太多辩论，并且人们坚信它们是现代且正确的选择。使用对象关系映射器（ORM）——即对象关系映射工具，如 .NET 中的实体框架或 Java 中的休眠框架——就是其中之一。这并不是批评 ORM 作为一种工具；在许多语境下，它们是出色的解决方案。问题在于，当人们在复杂、大规模的系统中，未经认真分析后果就将其采用为数据访问的基础架构时，问题便出现了。
将 ORM 作为默认决策
在大多数中型团队中，选择 ORM 并非源于深入的架构分析。它是快速交付压力以及开发人员对该工具熟悉程度的结果。ORM 显著减少了初期的摩擦：它允许在不编写结构化查询语言的情况下与数据库交互，并在几分钟内看到结果。这具有价值。问题在于，这种便利性掩盖了一种并未消失、只是被推迟的复杂性。而当这种复杂性出现时——而且它总会出现——往往是在系统已经拥有用户、数据量已经庞大、且没有人有时间进行重构的时候。
共享可见性的问题
在具有一定规模的系统中，数据团队看到的是执行计划、索引和慢查询，而不是生成这些查询的代码。开发人员看到的是对象模型和语言集成查询，而不是 ORM 实际生成的内容及其对数据库引擎的影响。介于两者之间的是 ORM，它作为一个黑盒，将一个世界翻译成另一个世界，而两个团队都无法真正控制这种翻译。
结果是可预见的：数据团队整天都在添加索引和调整统计信息，却没有解决根源问题，而根源往往是由 ORM 构建的不良查询，任何索引都无法挽救。索引可以改善低效的查询，但无法将其转变为设计良好的查询。
关于可移植性的论点及其他迷思
关于可移植性的论点——即能够在不触碰代码的情况下更换数据库引擎——在理论上听起来合理。但在实践中，对于拥有多年历史的成熟系统而言，这几乎是一种幻想。牺牲日常性能以准备应对可能永远不会发生的事情，并不是审慎的架构：这是焦虑的架构。关于版本控制的论点也站不住脚：借助 SQL Server 数据工具中的数据库项目、Flyway 或 Liquibase 等工具，数据库对象生活在具有完整历史记录和持续集成/持续部署集成的代码仓库中。在 2026 年，这一论点在技术上是薄弱的。
职责分离与存储过程
反对存储过程的最有力论点是职责分离：如果存储过程包含业务逻辑，那么属于应用层的东西就驻留在了数据库中。这是一个真实存在的问题。但有一个经常被忽视的区别：决定客户是否获得折扣的存储过程混合了职责；而在数百万条记录上执行复杂连接操作的存储过程，则正是在做它该做的事，靠近存储数据的引擎。问题不在于工具，而在于如何使用它。关键的区别在于，编写糟糕的存储过程是一个已知且局部化的问题；而配置不当的 ORM 会产生模糊且涌现的问题，随着系统扩展，这些问题会以意想不到的方式出现。
为什么技术权威并不总是有帮助
开发人员 q
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
