[Web]ORM模式的看法

在看各种语言建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模块更让人放心?

 

posted @ 2018-08-21 10:26  oDoraemon  阅读(375)  评论(0编辑  收藏  举报