在遙遠的編程大陸上，一條大河分隔了整個大陸。河的西邊住着一羣瘋狂的程序員，他們瘋狂的崇拜着OO大神，他們以OO大神規定的教義要求自己和自己的身邊的一切，他們把自己的首都叫做OO城。但是 不如意的是，大陸上的美女，都集中在OOfans的對面：東岸。 河的東岸(數據庫之領)住着崇拜“關係”女神的部落。雖然在程序員們的不斷的聖戰下很多部落的蠻人都偷偷信仰了OO大神，但是這一切都是不公開的。“關係”女神仍然籠罩東岸，並看來不可動搖（雖然有一些小部落宣稱摒棄“關係女神”（ODBMS-對象型數據庫管理系統））。
終於，有一天，OO城程序員們爆發了，他們聲稱他們受夠了在漫長的走到河邊之後還需要游泳（ODBC類）才能到東岸泡美眉的日子。既然將大陸融爲一體的地殼變動還需要等很久， 他們決定不再等待，一種叫做OO之船的東西（ORM）被迅速的製造出來並被聲稱可以極大的改善程序員的泡妞之路， 西岸因爲OO之船而振動，OO之船的理念和設計圖傳遍了大陸，無數的程序員們架着因爲製造者的不同千奇百怪的OO之船們開始了自己的泡妞之行。
OO之船得到了OO城船員的高度好評，但是鬱悶的OO城船員們也發現，在漫長的河的沿岸，只要是程序員聚集的城市，擁有一種叫做helper橋的東西橫跨在兩岸。helper橋是每個OO村莊千百代河岸程序員辛苦工作的結果。與每個人都要攜帶OO之船不同的是，他要求每個岸邊的程序員都趕到附近的helper橋，然後再利用helper橋踏上自己的泡妞之旅。
OO城的程序員因爲食古不化的河岸程序員而憤怒，尤其有些破舊的helper橋居然還是使用”過程”邪教的方法製造出來的。
在等待地殼變動的日子裏（dlinq，ODBMS），無數仍然使用游泳過河的西岸人觀望着OO城的程序員，期待把自己解放的一天。無數的OO之船員看着自己每天揹負的OO之船，思索自己是否需要每天都揹着這個傢伙。船，還橋 還是別的什麼，才能讓程序員們更輕鬆的趕到東岸美女的面前，程序員們困惑了。
ORM構架相較傳統的普通型（請原諒我使用這個詞，因爲我不知道該使用什麼來形容他）提供了先進的“對象－關係”映射，他存在最大的意義在與試圖消除關係型數據庫結構與面向對象編程中不可逾越的鴻溝。與激進的dlinq，ODBMS不同，他並不試圖改變目前的代碼構架或是數據庫結構，他只是一個橋樑，試圖將複雜兩個完全不同的構架連接起來並提供一種簡單而便捷的手段來方便別人使用。
圍繞這座橋樑，無數的人員參與了它的設計與建造，而且因爲意思形態的不同，圍繞ORM，他們產生了無數的話題和創意。ORM由原來的設計模式轉變成爲了一個龐大的構架，他向想越過對象－關係之河的人們提供工具，並採用了很多方法，試圖減輕使用這一工具所帶來的副作用。但是，我們真的需要ORM框架嗎？
下面就本人的一知半解來闡述下ORM的不足。
ORM的核心概念是O->M的轉換，軟件設計因爲OO，而獲得極大的發展，軟件開發的效率得到了很大的提升。但是一個問題被引發，OO化軟件編寫與關係形數據持久不匹配成爲了軟件開發中的一個障礙。ORM就是試圖將數據持久的數據轉化爲OO的對象的方法方便開發。這個概念相當不錯，但是在實際使用中卻有着不少問題。下面我一一道來。
首先，ORM是站在“對象”的觀點來觀察周圍的一切。但是在實際中，關係型數據庫存在一些不可逾越的使得限制使用ORM必須要付出相當的代價。
我們的軟件模型可能不止關注與”對象”個體的屬性，而在很多情況下需要對多個”對象”的屬性進行研究。
比如，我需要獲知一個簡單類型的值，他可能是一系列對象實例的屬性集合的一個描述，比如票房排名前一百的電影的導演名。可能對象”電影”是一個擁有無數屬性的對象，這對面向OO編程沒有什麼影響，但是爲了獲取這個簡單的值，我必須要加載符合條件的所有電影實例來進行導演名的遍例嗎？如果不是一百個電影，而是前一百萬個顧客名稱，我估計還是不得不去加載所有顧客。或許我們可以來對象化電影的導演名，但是如果我們需要製作一個工具，用戶可以決定他關注的電影範圍，來觀察其任一個屬性（而不是展示全部屬性），我們只有加載全部對象實例了。
大量的垃圾數據交互顯然自不必說，爲了實現我們的目的，我們只能無奈的去複雜化我們的代碼，這是我們的初衷嗎？這所帶來的一系列的問題由誰來買單那？
另一方面，如果我關係的簡單類型的值，他可能是一個與”對象”無關的描述。比如我需要知道一個連續ID列值有哪幾個缺失了。ORM就無能爲力了，因爲我們無法描述不存在的東西。除非製造出一個專門的對象來實現，但這也是自找苦吃的方法。
第二：
對象型和關係型的基本立足點就不一致，對象型強調的是OO,關係型的核心理念是第三範式，甚至是BCNF。因爲代碼需要的是簡單明瞭的對象模型，OO擁有繼承和多態，喜歡的是對象具有全面的屬性。比如我設計一個汽車類，他包含汽車需要的輪胎種類，出於編程的便捷性，我當然喜歡汽車會有一個屬性直接表示輪胎種類。但是站在數據庫的角度上，出於擴展，簡化或性能的考慮，我可能被迫使用汽車－>輪胎類型號->輪胎類型名稱的設計。當然，或許這可以使用一個簡單的外鍵級聯，使”輪胎類型”對象成爲”汽車”對象的屬性來解決問題（這裏也包含上面所說的問題，無效的加載）。但是很可能的這不是一個級聯，我不希望他們使用外鍵關聯（比如數據倉庫項目）。那我就必須作出犧牲原則的抉擇，OO還是Relation？這是個問題。
ORM優勢和缺點：
優勢：ORM自其概念被提出，就得到了無數的響應，花樣繁多的應用框架更是應接不暇。可見，他是有其獨到的優勢的。那麼他的優勢有哪些那：
首先，ORM最大的優勢。
隱藏了數據訪問細節，“封閉”的通用數據庫交互，ORM的核心。他使得我們的通用數據庫交互變得簡單易行，並且完全不用考慮該死的SQL語句。快速開發，由此而來。
第二：ORM使我們構造固化數據結構變得簡單易行。
在ORM年表的史前時代，我們需要將我們的對象模型轉化爲一條一條的SQL語句，通過直連或是DB helper在關係數據庫構造我們的數據庫體系。而現在，基本上所有的ORM框架都提供了通過對象模型構造關係數據庫結構的功能。這，相當不錯。
缺點：
第一：
無可避免的，自動化意味着映射和關聯管理，代價是犧牲性能（早期，這是所有不喜歡ORM人的共同點）。現在的各種ORM框架都在嘗試使用各種方法來減輕這塊（LazyLoad，Cache），效果還是很顯著的。
第二：
面向對象的查詢語言(X-QL)作爲一種數據庫與對象之間的過渡,雖然隱藏了數據層面的業務抽象,但並不能完全的屏蔽掉數據庫層的設計,並且無疑將增加學習成本.
第三：
對於複雜查詢，ORM仍然力不從心。雖然可以實現，但是不值的。視圖可以解決大部分calculated column，case ，group，having,order by, exists，但是查詢條件(a and b and not c and (d or d))。。。。。。
世上沒有驢是不吃草的(又想好又想巧,買個老驢不吃草)，任何優勢的背後都隱藏着缺點，這是不可避免的。問題在於，我們是否能容忍缺點。ADA代碼雖然易用性很差，但是US.DoD（the department of defense）欣賞他的運算速度；.net平臺很不錯，但是他是MS的。^_^
ORM爲何而生
在數月以前，我有幸參加了一個公司內部的組件發佈會。令我深感意外的事，一向無人關心的組件發佈會這次變得人山人海，在漫長的新版本介紹之後。每個開發組長都跳出來抱怨上一個版本的問題，並且宣佈與剛發佈的新版本也是無法滿足他們的需要的。一切都是如此的混亂，以至領導層不得不採用鎮壓的方式來平息怒火沖天的人們。
在會後的那個晚上，我仔細回想了這次衝突。因爲據我瞭解，這一系列的組件非常完美的完成了他所被期待的功能。可是爲什麼還是會被抱怨如此那。
我覺得，可能，他(組件)是沒有被正確使用了。
不知道還有誰記得James Elliott的那句話，
As good object-oriented developers got tired of this repetitive work, their typical tendency towards enlightened laziness started to manifest itself in the creation of tools to help automate the process. When working with relational databases, the culmination of such efforts were object/relational mapping tools.
ORM構架只能是一個helper，他定位與此，而不是完整的數據持久層。他的設計者從來就沒把他定位於取代一切的超級美女。ORM致力爲長久以來的程序員與”重複勞動”的戰爭而助拳。與任何一個helper一樣，他有自己的不足，他有優點也有缺點。
無數的開發人員試圖將使用ORM的框架構架自己項目的數據持久層，很多人感受到了ORM的優勢，他們歡心鼓舞。但是很不幸，也有很多人失敗或是深受蹉責。
還有許多人，無奈的編寫着很多ORM不適合作的事情。其實想一想，被自己捨棄了的以前的helper工具，難道真的一無是處了？
ORM與DB Helper Library：
很多人可能都接觸過這類的helper，每個公司都有自己的helper。許多Helper提供了很多的強大的功能，封閉交互底層，實體類支持，提供SQL翻譯功能。ORM比之這些Helper只是多提供了一層，他嘗試封閉的自動化的（或是映射文件）來實現關聯。以前，這都是我們手打的。（靈活替換數據庫也算ORM優點，
）
問題就在與有些人發現封閉的自動化關聯滿足他們需要了，所以ORM對他而言是成功的。而有些人發現封閉的自動化關聯不適合他們的項目，所以ORM被詬病。
寫到這裏，我想不用多言了。該結束了。
我的觀點是ORM試圖取代helper，爲此提供了更多的功能。他爲了應付更加嚴格和複雜的企業需求而不斷髮展，在很多情況下，這些工具開始具有自身的複雜性，使得開發人員必須學習使用它們的詳細規則，並修改組成應用程序的類以滿足映射系統的需要，使用它們所面臨的複雜性反而蓋過了所能獲得的好處。在我們的大部分項目中Helper依然是我們構建數據持久層的主力，ORM或許在有些項目(模塊)中可以獨攬一切，但是ORM（就目前而言）無法面對一切考驗。
有一天，馬可問上帝：‘偉大而萬能的主啊！編程大陸的程序員們因爲OO之船與helper橋而困惑。迷途的羔羊發出無望的慘叫，您爲何不可憐他們。將大河消除兩岸合一，或者賜於他們神奇的法器讓他們渡河那’。
上帝說：‘馬可，你的憐憫之心甚好。但是你可曾看到，那喧囂的聲音不是無望的慘叫，而是他們爭執的喊聲。你不曾瞭解，正因爲那河，他們的生活才存在意義。即使我消除了那河，程序員們還會因爲別的什麼而爭吵。’
馬可問上帝：‘這是爲什麼那，難道快樂的生活不好嗎？’
上帝說：‘那是程序員的宿命啊。他們因爲無法剋制的好奇而踏上探索之路，他們通過爭執而發現方向，他們因爲挫折而反省，他們爲了探求編程大陸的奧祕而一代一代不斷追尋。馬可，總會有一天，他們會來到我們這裏，這點我深信不移’
馬可說：‘真是羣可憐而無畏的孩子啊！’
上帝說：‘凡是追尋真理的人們都將永生，即使死去的，也必復活！
轉自：http://hi.baidu.com/loongg/blog/item/c23585a8436cb6b7ca130c6b.html