啊，是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來得高啦。
最後總結一點就是，不要在一棵樹上吊死，最關鍵的是，軟件的結構要清晰，執行效率要滿意
