我的CMS开发记-2 该ORM就ORM,该写SQL还是写SQL

     啊，是ORM还是SQL,这是个问题.

     先扯段题外话，我原来公司的产品是java和.net共存，java部分是外包的，于是么各位也可想而知，两派程序员遇到一块会发生什么事情-____-;;好在大家都是文明人，口水战之后，各取所需，我也是从他们那里得来的MVC,HIBERNATE等等框架方面的概念，从而才得知世界上还有这样的编程思想。当然他们也被本人惊天地泣鬼神的SQL查询功力所震惊(先吹吹牛再说),无数看似复杂的报表问题在sql语句的魔力下谈笑间灰飞烟灭，两者各有各的好处.

      那么我在开发的时候就遇到这样的问题，ORM能极大地解放生产力，在做后台维护的时候，那代码是无比简洁，而且再也不用去担心什么字段拼错啊，漏字段啊什么什么乱七八糟的破事，只要去管需要实现的功能即可。我们以文章发布模块为例，使用ORM后的开发过程是这样的，我首先创建 文章 的实体类，反正不外乎就是什么标题啊，内容啊，副标题啊，XXOO就那些东西，然后，连表都不用建，直接用实体类就可以生成表，增删查改一应俱全。在展示的时候，使用orm的查询，连sql注入都自动给你防了,看起来真不错。

      恩，是不错。但是这里却有个异常严重的问题，文章录入是当然没有问题，可是在文章列表页，毛病就来了。首先第一个大问题，就是查询问题。文章列表页，只需要显示文章标题即可，大段大段的文章内容根本就用不着去查出来。去查这些东西无疑是极大影响效率。但是这个时候你就会发现：使用orm是处处受制，他要么就是根本就没法定制字段，要么就是非常麻烦。以我使用的Castle ActiveRecord（内部调用Nhibernate）为例，不错他确实可以使用本地sql语句，但是你使用的话必须把字段全部写全，而且时常会遇到莫名奇妙的问题。其实我的要求非常简单，我就只是想取前10条标题，干嘛非要大动干戈绕一个大圈子？好吧反正不就10条文章么，浪费也浪费不到哪去，我忍了。

     但是，如果现在我加点料，我要从某个分类，或者某几个分类里头取头几条，还要考虑置顶，推荐等等因素，这下麻烦大了。activerecord那可怜的一点点查询条件压根没法满足如此复杂（虽然实际上不复杂）的查询，好吧那我用HQL,经过一番研究，hql是写出来了，可是他自动翻译成的sql语句实在是比手写的sql要差了不少，而且使用子查询时写法之晦涩难懂实在是。。。写过就忘了。

     于是经过痛苦的抉择之后，我决定，嘿嘿，遭鄙视就遭鄙视，同时使用sql和orm。orm用于网站后台维护，前台展示，还是使用本人苦练多年的SQL查询,嘿嘿，做人不能忘本是不是，当然了，咱也不能干满页面拼SQL这种太落伍的事情，适当的封装一下，把展示用的页面和数据直接分分开，代码写得清楚一点，也不见得就坏到哪里去，不过执行效率却是上来了。

     由于使用了ORM框架，目前可以同时使用sqlserver和access,其他数据库尚未测试，那么直接用sql查询的页面也需要准备一个数据库访问层，同时支持sql和access或其他，这个大家都会，没啥好说的，根据我以前做财务软件实施维护的经验，其实呢标准的sql语句各大数据库也都差不太多，子查询，连接等语法都是通用的。还是那文章列表来说，无非就是

     select top 10 title from article where ....这类写法，简单明了。

 就select语句来讲，绝大多数需求都能写出各种数据库通用的写法，即使实在是找不到通用写法，那么这时候采用反射等手法来同时支持多数据库，反正sql语句的效率一定比orm来得高啦。

     最后总结一点就是，不要在一棵树上吊死，最关键的是，软件的结构要清晰，执行效率要满意