O/R M一個相當常見的概念，不過也是一個被很多人誤解的概念。O/R M據我所知是從Java社區(qū)產生的，而到了.Net社區(qū)它的意味就完全變了。首先讓我們來看看為什么是O/R M而不是R/O M？其實之所以很多人沒有理解O/R M的含義就是因為沒有充分的考慮上面這個問題。
以O為主還是以R為主？你是從面向對象的角度分析考慮問題還是從關系的角度分析考慮問題。
從面向對象的角度考慮問題，意味著你可以使用封裝，集成，多態(tài)這些面向對象的特點來描述和理解你的應用域，因為對象的高度抽象和可理解性，通過它你可以構造出一個用對象來描述領域的模型，這也是領域模型的由來。而一個好的模型必然要考慮到的幾點包括對象所包含的責任是否合理，對象與對象之間的關系是否合理等，而高內聚，低耦合就是用來衡量它們的一個技術標準。
可以看出一個好的領域模型，可以讓你清楚的了解現實的應用領域，而一個好的領域對象也必然具有高內聚，低耦合的特點，而絕對不是一個數據包。
當我們使用面向對象技術建立好了我們的領域模型，一個問題隨之而來，對象如何持久化？對象的生命周期包括多個階段其中包括第一次被創(chuàng)建出來，被持久化，被從文件(通常是數據庫)中取出來，被垃圾回收。顯然我們希望能夠更多的關注與領域模型而非這些對象生命周期的管理，此時O/R M的需求應運而生，而能夠透明的實現對象的持久化和反持久化則更為我們所追求，此時再來看看某些使用O/R M來為一個領域對象實現Save Load的做法是多么與我們的想法背道而馳，這些方法與領域何關？O/R M框架將對象持久化功能從領域對象中分離出來，交由框架負責，而有人竟然反其道而行之，這種現象在.Net社區(qū)尤為常見。為什么會這樣？因為考慮問題的思路不同。可以這么說在.Net社區(qū)O/R M往往被當作R/O M來使用。
從關系型模型的角度來考慮問題，在一接到問題之后，先建立實體關系模型，然后考慮各種約束條件，并通過Server端一系列的存儲過程來描述業(yè)務邏輯。這種方法曾廣泛被采用，然而兩相比較孰優(yōu)孰劣？和大多數人(Martin Fowler等等)一樣我更喜歡OO的方式，用對象來描述世界，比起關系和一堆的SQL語言對我來說，顯然前者更美，而且沒有了繼承多態(tài)，那樣程序將充滿了重復代碼，并且不利于擴展，可讀性就更不用說了。就如Martin Fowler所說要不是因為.Net提供了方便的界面綁定方法，這種純粹的數據包對象誰會去使用呢？它們的優(yōu)勢就在于那些領域邏輯簡單的應用，這也是.Net常見的應用領域。
所以當你不是用對象的方法(不是說你僅僅使用了面向對象語言)來分析解決問題時請離O/R M遠一點，這樣對大家都好。你不會覺得它奇怪，它也不會被你用的郁悶。
在這里我也順便談談我對DLinq的看法。首先我不得不承認它很Cool,并且我之前對Linq也做過介紹，但是我并不是很喜歡它的方式，至少它存在一種可能被濫用的危險。查詢你所需要的數據，然后圍繞這些數據做處理，微軟仍然堅持它一慣的風格，并且在Linq中，可以說是做到了極致---用Linq查詢數據太方便了。如果每個對象都通過這樣的方式獲得，那么對象之間的關系(Association)將變的雜亂無章。你在設計對象的時候仔細考慮的對象之間的關聯(lián)關系將被輕易的打亂(領域對象的關聯(lián)關系是描述領域模型的關鍵組成部分之一)，而且你查詢到的純粹是數據實體，它們并沒有行為，你又會靠一個個的xxxManager來管理它們，喔，天哪，又失去了面向對象的優(yōu)勢。所以DLinq本身絕對不是一套O/R M工具，不過利用它實現一套O/R M工具倒是不錯的選擇。
當面對面向對象和關系型數據庫的阻抗失衡時，Java社區(qū)更多的考慮的是自動透明的實現將O映射成R的方式，而MS更多的考慮的是將R方便的變成O(數據包類型的O而已)的方式(這點可能跟MS也是數據庫廠商有關)。兩個方向，你選哪個？
個人觀點僅供參考。
BTW 前陣子有個兄弟問我O/R M的性能怎樣？呵呵，總是有很多人關注性能問題。那么我先問問大家
你覺得OO性能怎么樣？泛型性能怎么樣？AOP的性能怎么樣？SOA的性能怎么樣？呵呵，另人失望的答案，它們的運行效率都比不使用它們的方案低。但是它們能大大加強我們的開發(fā)效率，這是一個追求效率的年代 :)
(我可沒有鄙視性能的意思)
6.8看過評論后更新
本文的觀點可能有很多人有不同意見，這很正常，如我標題所寫本文也僅僅是亂談而已。不過對于使用Hibernate的用戶請盡可能的考慮我所說的問題，因為我的觀點和Gavin King(Hibernate的作者)的還是基本一致的。同樣對于大家所說的表很多的問題，請參考Gavin King的原話。
You should use Hibernate if you have a nontrivial application (definition of nontrivial varies, but I usually think of Hibernate being less applicable to applications with only ten tables or so) that use an object-oriented domain model. Not every application needs a domain model, so not every application needs ORM. But if your application does a lot of business logic - rather than just displaying tabular data on a webpage - then a domain model is usually a good thing.
Hibernate really starts to shine in applications with very complex data models, with hundreds of tables and complex interrelationships. For this kind of application, Hibernate will take away a huge amount of coding effort (perhaps up to 25%, for some applications) and will result in an application that performs better than the alternative handcrafted JDBC. This is possible because some kinds of performance optimizations are very difficult to handcode: caching, outer-join fetching, transactional write-behind, etc.
另外雙魚座在評論中指出"數據規(guī)模對采用哪種技術框架沒有太大關系，有比較大關系的是業(yè)務復雜度", 對此個人深表贊同。
如果你想深入理解O/R M，推薦以下三本書：
Patterns of Enterprise Application Architeture
Hibernate in Action
Domain-Driven Design
相關文章
浙公網安備 33010602011771號