在看各种语言建Web资料的时候，无一例外的都提到了ORM的设计模式。
不过从个人实践来说，ORM给我带来了不少痛苦。痛苦主要来自几个方面。
首先是文档。
ORM框架在各个语言中都有自己的实现，每一个模块都是值得大书特书的存在，随便一翻都有1-200页的manual，多数文档结构并不友好。对比下来学习SQL的成本是否更低一点？
尽管仅仅走Quick Start的话倒是够快，但感觉不了解具体的实现原理总有点不太放心。
其次是业务需求。
一些数据结构比较容易抽象为对象，可以创建Model，这时候使用ORM进行查询是比较愉悦的。
然而在我工作中日常处理的是一些数据业务的需求，数据逻辑并不总能抽象为对象。极端一点倒是可以将每个表抽象为对象，建一个Model，但细想总觉得逻辑不合理。尤其当数据库和数据表都不在自己掌控范围内时，复杂查询/subquery/连表查询的问题变得十分突出，单用ORM查询无法满足业务需求。
最后是性能方面的不确定性。
可能是SQL先入为主，自己对写出的SQL总有一个性能上模糊的认识，比如执行过程大概怎样，是否使用索引，使用了哪些索引等。
而使用ORM则没有这方面的概念。有时候我并不确定查询是否有利用索引，会不会出现慢查询，有没有全表扫描等。
想要深入了解，但尝试了几次SQLAlchemy的文档，总是头皮发麻，无疾而终。
最近搜到了同样diss ORM的内容，ORM是明显的反模式。多少有点共鸣的感觉。
文章中提到了ORM的各种优缺点。
对我来说，ORM优点仅在于语言表达一致性更好，易于维护，集成性更好。
至于让程序员不用学习复杂的SQL?
Quick start SQL的成本真不比看ORM文档的成本多多少。虽然SQL文档普遍可读性很差，但ORM的文档也真是半斤八两。
至于MVC中的Model层，也应该合理的抽象对象。对一些不适合抽象为对象的数据，强行建Model并不是一个好办法。
如果纠结项目成员间代码的规范和可读性，要保证后期代码的可维护性，一份清晰规范的文档是个不错的解决方案。
至于在我自己的项目实践中，易于抽象且数据量不大的数据结构如用户表、权限表等，我是乐于创建Model并通过ORM进行查询的。
但是涉及到数据分析或者复杂的业务逻辑时，我则更倾向于使用原生的SQL语句解决。
尽管SQL的可维护性是个隐患，不过可能是工程不大的原因，目前vscode的全局搜索处理还很方便，修改起来并不麻烦。
至于更好的解决方案，可能自己实现个简约版ORM模块更让人放心？