为什么不推崇复杂的ORM

上一篇文章写完，回复的人很多，有的说的很中肯，有的貌似只是看到文章的标题就进来写评论的！还有人问为什么我要屏蔽掉【反对】按钮，因为谁写文章都是为了分享，都在说出自己的心得体会。不过由于大家遇到的项目，做的东西，见过技术各有差异，很难让每个人都向一种意见靠拢。所以你可以不喜欢，但是请不要作恶！

评论中*深海， lindping说的是通用的ORM可以为通用产品带来部署的便利！dax.net，深蓝医生，路过秋天说的是ORM一个很关键的作用就是可以加快开发速度！还有些属于性能控，对SQL比较推崇。还有些没有明白表达的意图，语文是音乐老师教的！实在抱歉！

先说下部署这个问题，如果是做通用产品的话，考虑到各种数据库的兼容确实能带来很多好处。这一点我很认同，不过从业开始但现在，接触过的项目基本上都是属于定制类的，所以这一点没能感同身受。有过一次，不过不是换数据库这么简单，而是换整个部署方案，从WINDOW平台换到LINUX上，数据库从MSSQL换成ORACLE。没用ORM，用的SQLSHOP+存储过程的方式来做的系统，前后一个星期全部完工。因为SQLSHOP的SQL都是可以人工干涉的，存储过程这一类的调用也是放在SQLSHOP里面，所以我们基本上没有动一行代码，都是通过机器生产和人工的方式来修改存在XML里面的SQL，效果还可以。也是因为这次的经历，我才发现原来MSSQL和ORACLE其实差不了多少，存储过程，SQL函数，调用的语法，性能等等.Mono加JEXUS，有时比IIS还给力。

开发效率是评论中比较让我纠结的。因为我不是说我不用ORM，而是我觉得ORM设计的太复杂，没有什么太大的意义（原文第四句哈）！

主流的数据库，其增【INSERT INTO . (.,.)VALUES(.,.)】，删【DELETE FROM . WHERE ...】，改【UPDATE . SET .=. WHERE .=.】的语法都一样，这部分可以抽象，做出一个支持CUD（没有R）的系统。

但是查询就不是那么简单了，人们对数据的关注点不一样，所以需要的查询语句就不相同。不是所有主流数据库都有一个相同的查询系统，所以这一部分很难抽象。

所以没有一套ORM能很完美的处理了查询问题。

1.语法上，没法做到比SQL更简洁。

2.语义上，各库SQL方言的差异很大。你需要为每个主流数据库写一套不同的SQL方言系统，你需要了解各种库SQL的特点。

3.语用上，你需要动态生成符合当前情景的SQL。比如你做分页，每种库纯SQL的分页方言就有很多，每种分页在不同的分页情景下效率是不同的，最优的情况是你可以动态去判断情景。

上述三点，不说第三点。前两个弄得很好的ORM，开源的NHibernate没有做到，微软自己的EF没有做到，商用的LightSpeed也没有做到。目前的ORM都是在1和2上下功夫。3很难，而且对需求如此苛刻的也不会使用ORM了。所以，我倒是觉得与其活生生的坑在这三点上，倒不如从以下几个方面好好考虑一下，数据库支持，功能支持，语法支持，映射支持等。比如：

1.考虑下NOSQL吧，可以做完整单表映射或NOSQL数据的对象映射。

怎么支持RavenDB，STSdb，MongoDB，Cassandra等？

2.考虑下DDD吧。功能齐全的CUD系统，能否很好的支持CQRS中C？

怎样快速从数据库中映射出运行时对象？反射，EMIT，表达式？

怎么提高缓存的命中？支持Memcached，还是使用自己实现的？

3.考虑下支持OO原生特性，因为需要拿ORM来表达业务流程，是站在OO的角度考虑问题而不是数据库。那么你的ORM就需要考虑一些数据库问题了。

怎样为有继承关系的对象设计表？共享同一张表，还是分开，然后使用字段关联？

怎样选择更新时的充血或贫血？充血和贫血都有优缺点，怎样选择？

业务对象是可以用户实例化的还是只能由ORM实例化？用户实例化和ORM实例化各有各的好处，选择哪个?

可否为对象及对象的属性添加拦截？能够知道系统中最热对象是哪个，最热属性是哪个，由此可以得出一些很有意思的信息在，怎么设计？

......

这实在是太多了，不管是细节还是宏观上，都太多了。

4.考虑下支持从数据库直接映射成XML或JSON吧，或把XML或JSON直接转换为SQL吧，虽然XML和JSON不是对象，但是越来越多的地方使用XML或JSON来做对象容器。

说完查询SQL生成的复杂，再说业务逻辑的问题。把复杂逻辑放在代码，还是放在数据库里面。其实这个也很让人纠结。站在数据库的角度想，在离数据越近的地方处理数据越快，所以放在数据库里面吧。但是站在代码的角度考虑，各种对象组合在一个表达了一套完整的业务流程，用OO的方式去考虑这个流程远比使用数据库表结构去表达要好很多，所以放在代码里面吧！......评论中地狱门神的评论很直接，我也很想这么做。但是有时候，完全使用代码去完成一套业务流程是不靠谱的。使用存储过程的时候，一切都是在数据库中，少了从数据库表到运行时对象的转换，肯定会快很多。而且业务流程越复杂，这一点体现的越明显。如果你的系统中有个部分是和很多表关联的，比如权限模块，你用ADO.NET到OBJECT，再处理OBJECT，再使用OBJECT和ADO.NET获取新的OBJECT的这种串行化的方式处理业务流程，当表的关联到达一定程度的时候，那个速度是完完全全不能忍受的。这个时候就需要使用存储过程了。

所以根据以往的经验，使用存储过程的地方主要是两点。

1.如果有部分的业务变化比较频繁并且有一些性能要求，使用存储过程吧，这样在系统运行时就能轻松的修复一些问题。

2.如果一个流程关联的表比较多（多于3张以上的表），而且每个表的数据都超过1W，那么也用存储过程吧。

如果对性能要求不高，表关联也不多，业务流程很简单，那就可以使用代码的方式来表达业务流程了。

所以，想想吧！

复杂查询SQL，就算是再复杂的ORM也玩不来的，与其如此，倒不如设计的简单易用些。

不要再为ORM考虑怎么全部的CURD都是对象操作，怎么全部的查询SQL都是自动生成，怎么设计支持多表关联了。

作为程序员，何必活的那么复杂，大道至简！

补加一段我下午5点的评论（评论31楼）！

现在所有的ORM都是以解决对象的CURD为目标的！

但是！
数据库集群的时候，读写分离！
CQRS中把C和Q会分开！
所以！
原本R和CUD就不是一类，但是非要用ORM来动态生成！
生成的结果又也不一定好，也不能充分体现每种数据库自己的优势！
与其如此，倒不如把CUD做好，把R外置出去，做到可以人为干涉！
因为我自己一直在做ORM，也希望做的完美!
C#写的ORM，我用过的不一定你都用过！
用的越多，自己做的时间越长就越觉得R和CUD不是一类！
所以就希望把R从ORM中外置除去，做到所有生成的SQL可以手动干涉！
开发效率不会比你直接调ORM的SQL慢，但是效率绝对不比你慢，修改绝对比内置在ORM内部要方便，觉得那个SQL生成的不好，还可以手动去改！
这就是把R和CUD分出去的好处！
现在的ORM，那个能做到这么灵活！