從面向對象的角度考慮問題，意味著你可以使用封裝，集成，多態這些面向對象的特點來描述和理解你的應用域，因為對象的高度抽象和可理解性，通過它你可以構造出一個用對象來描述領域的模型，這也是領域模型的由來。而一個好的模型必然要考慮到的幾點包括對象所包含的責任是否合理，對象與對象之間的關系是否合理等，而高內聚，低耦合就是用來衡量它們的一個技術標准。
可以看出一個好的領域模型，可以讓你清楚的了解現實的應用領域，而一個好的領域對象也必然具有高內聚，低耦合的特點，而絕對不是一個數據包。
當我們使用面向對象技術建立好了我們的領域模型，一個問題隨之而來，對象如何持久化？對象的生命周期包括多個階段其中包括第一次被創建出來，被持久化，被從文件(通常是數據庫)中取出來，被垃圾回收。顯然我們希望能夠更多的關注與領域模型而非這些對象生命周期的管理，此時O/R M的需求應運而生，而能夠透明的實現對象的持久化和反持久化則更為我們所追求，此時再來看看某些使用O/R M來為一個領域對象實現Save Load的做法是多麼與我們的想法背道而馳，這些方法與領域何關？O/R M框架將對象持久化功能從領域對象中分離出來，交由框架負責，而有人竟然反其道而行之，這種現象在.Net社區尤為常見。為什麼會這樣？因為考慮問題的思路不同。可以這麼說在.Net社區O/R M往往被當作R/O M來使用。
從關系型模型的角度來考慮問題，在一接到問題之後，先建立實體關系模型，然後考慮各種約束條件，並通過Server端一系列的存儲過程來描述業務邏輯。這種方法曾廣泛被采用，然而兩相比較孰優孰劣？和大多數人(Martin Fowler等等)一樣我更喜歡OO的方式，用對象來描述世界，比起關系和一堆的SQL語言對我來說，顯然前者更美，而且沒有了繼承多態，那樣程序將充滿了重復代碼，並且不利於擴展，可讀性就更不用說了。就如Martin Fowler所說要不是因為.Net提供了方便的界面綁定方法，這種純粹的數據包對象誰會去使用呢？它們的優勢就在於那些領域邏輯簡單的應用，這也是.Net常見的應用領域。
所以當你不是用對象的方法(不是說你僅僅使用了面向對象語言)來分析解決問題時請離O/R M遠一點，這樣對大家都好。你不會覺得它奇怪，它也不會被你用的郁悶。
在這裡我也順便談談我對DLinq的看法。首先我不得不承認它很Cool,並且我之前對Linq也做過介紹，但是我並不是很喜歡它的方式，至少它存在一種可能被濫用的危險。查詢你所需要的數據，然後圍繞這些數據做處理，微軟仍然堅持它一慣的風格，並且在Linq中，可以說是做到了極致---用Linq查詢數據太方便了。如果每個對象都通過這樣的方式獲得，那麼對象之間的關系(Association)將變的雜亂無章。你在設計對象的時候仔細考慮的對象之間的關聯關系將被輕易的打亂(領域對象的關聯關系是描述領域模型的關鍵組成部分之一)，而且你查詢到的純粹是數據實體，它們並沒有行為，你又會靠一個個的xxxManager來管理它們，喔，天哪，又失去了面向對象的優勢。所以DLinq本身絕對不是一套O/R M工具，不過利用它實現一套O/R M工具倒是不錯的選擇。
當面對面向對象和關系型數據庫的阻抗失衡時，Java社區更多的考慮的是自動透明的實現將O映射成R的方式，而MS更多的考慮的是將R方便的變成O(數據包類型的O而已)的方式(這點可能跟MS也是數據庫廠商有關)。兩個方向，你選哪個？
個人觀點僅供參考。
BTW 前陣子有個兄弟問我O/R M的性能怎樣？呵呵，總是有很多人關注性能問題。那麼我先問問大家
你覺得OO性能怎麼樣？泛型性能怎麼樣？AOP的性能怎麼樣？SOA的性能怎麼樣？呵呵，另人失望的答案，它們的運行效率都比不使用它們的方案低。但是它們能大大加強我們的開發效率，這是一個追求效率的年代 :)
(我可沒有鄙視性能的意思)
6.8看過評論後更新
本文的觀點可能有很多人有不同意見，這很正常，如我標題所寫本文也僅僅是亂談而已。
