為什么我說ORM是一種反模式

更多的關于ORM的理解
服務器君一共花費了174.691 ms進行了5次數據庫查詢,努力地為您提供了這個頁面。
試試閱讀模式?希望聽取您的建議

上周我在在上討論了ORM,在那以后有人希望我澄清我的意思。事實上,我曾經寫文章討論過ORM,?但那是在一場關于SQL的大討論的上下文中,我不應該把這將兩件事情混為一談。 因此,在本文中我將關注ORM本身。同時,我盡力保持簡略,因為從我的SQL文章中顯而易見的是:人們傾向于一旦讀到讓他們發怒的內容就會離開(同時留下一句留言,而不論他們所關注的東西是否在后面會討論到)。

什么是反模式?

我很高興地發現Wikipedia有一個相當全面的關于反模式的列表,包括來自編程界及其之外的內容。我之所以稱ORM為反模式的原因是因為,反模式的作者定義了用來區分反模式和普通的壞習慣的兩個條件,而ORM完全符合這些條件:

  1. 它開始的時候看起來很有用,但是從長期來看,壞處要大過好處
  2. 存在已驗證并且可重復的替代方案

由于第一個因素導致了ORM令人抓狂(對我來說)的流行性:它第一眼看上去像是個好主意,但是當問題更加明顯的時候,已經很難離開了。

這對ORM來說是什么意思?

我想說的主要問題在于?ActiveRecord,它由于 Ruby on Rails 而著名, 從那以后已經移植到了許多其他語言。然而,這些問題同樣存在于其他的ORM層,比如Java的Hibernate和PHP的Doctrine。

ORM的優點

  • 簡單:一些ORM層告訴你它們“消除了對SQL的要求”。我至今仍然看到這種承諾在傳播。其他一些會更加現實地聲稱它們可以減少手寫SQL的需要,但是仍然允許你在需要的時候使用它。對于簡單的模型以及項目的早期,這確實是一個優點:使用ORM,無疑你能夠更快地開始啟動。然而,你將會走向錯誤的方向。
  • 代碼生成:使用ORM從模型中消除用戶層面的代碼,這一做法開啟了通向代碼生成的大門。通過對schema的簡單描述,“腳手架”模式可以為你的所有表生成一個可工作的界面。更加具有魔力的是,你可以修改你的schema描述,然后重新生成代碼,從而消除了CRUD。同樣,這在開始的時候確實是可行的。
  • 性能“足夠好”:我沒有看到任何ORM層聲稱在性能上更加優越。很明顯,為了代碼的敏捷性需要付出性能的代碼。如果哪里變慢了,你總是可以用更加有效的手寫SQL覆蓋你的ORM方法。不是嗎?

ORM的問題

1. 不充分的抽象

ORM最明顯的問題是它并不能完全從實現細節中抽象出來。所有主流ORM的文檔中到處都引用了SQL的概念。其中一些介紹的時候并不會表明其在SQL中的等價物,而其他一些則將庫看作用來生成SQL的過程函數。

抽象的要點在于它應該使問題得以簡化。對SQL進行抽象,同時又要求你懂得SQL,這使得你需要學習的東西成倍增加了:首先,你必須理解你正在試圖執行的SQL是什么,然后你還要學習ORM的API,來讓它為你編寫這些SQL。在Hibernate中,為了完成復雜的SQL你甚至需要學第三種語言:HQL,它幾乎就是SQL(但又不完全是),其在幕后被翻譯成SQL。

ORM的支持者會辯解說并非每個項目都是如此,并非每個人都需要復雜的join,并且ORM是一個"80/20"解決方案,其中80%的用戶只需要SQL中20%的功能,ORM可以處理這些問題。我能說的是,我15年來編寫web應用的數據庫后端的經歷表明,事實并非如此。只有在項目剛開始的時候你不需要join和本地join。在那之后,你就要優化和鞏固你的查詢。即使80%的用戶只用到SQL中30%的功能,可是100%的用戶都需要打破ORM的抽象才能夠完成工作。

2. 不正確的抽象

如果你的項目確實不需要任何關系數據功能,那么ORM可以非常完美地為你工作。但是接下來你又遇到另外一個問題:你用錯了了數據存儲。關系存儲的額外付出是非常高的;這就是為什么NoSQL數據要快得多的重要原因之一。然而,如果你的數據是關系型的,那么額外的付出就是值得的:你的數據庫不僅存儲數據,它還表達了你的數據,并且可以基于關系概念回答關于它的問題,這比你用過程代碼能夠做到的要快速得多。

但是,如果你的數據不是關系型的,那么你就是在不適當的場合使用SQL,這為你增加了巨大且不必要的負擔;為了讓問題更加嚴重,你在其上又增加了一重額外的抽象。

另一方面,如果你的數據是關系型的,那么你的對象映射最終會失敗。SQL是關于關系代數的:SQL的輸出不是對象,而是對于某個問題的解答。如果你的對象“是一個”X的實例,并且“擁有一些”Y,且每個Y“屬于”Z,那么對象在內存中正確的表達形式是什么? 它應該是X的屬性,或者全部包含在Y中,或者/并且全部包含在Z中?如果你只得到X的屬性,那么何時你運行查詢來獲得Y呢?而且,你是想要其中一個還是全部?現實中,答案是依賴于條件的:這就是為什么我說SQL是對于問題的回答。對象在內存中的表達形式取決于你的意圖,然而面向對象設計沒有依賴于上下文的表達這樣的功能。關系不是對象;對象也不是關系。

3. 多個查詢導致失敗

這自然的引出了ORM的另一個問題:效率低下。當你獲取一個時,你需要哪些屬性?ORM并不知道,所以它總是取得全部(或者它要求你告訴它,但是這又打破了抽象)。開始的時候這不成問題,但是當你一次取出上千條紀錄的時候,如果你只需要3個屬性卻不得不取出全部30列,這時就產生了嚴重的性能問題。許多ORM層非常不善于推斷join,從而不得不使用分離的查詢來獲取關聯數據。如前所述,許多ORM層明確聲明效率將會有所犧牲,其中一些提供了某些機制來調整引起問題的查詢。我從過去的經歷中發現的問題表明,很少有只需要調整單個“銀彈”查詢的情況:應用的數據庫后端之所以死掉不是因為其中某一條查詢,而是眾多的查詢引起的。ORM缺少上下文敏感的性質意味著它無法鞏固查詢,相反必須借助cache或其他機制來進行一定程度的補償。

那么替代方案是什么?

希望到這里我已經澄清ORM在設計上的一些缺陷。但是要作為一個反模式,還需要存在替代的解決辦法。事實上有兩個取代方法:

1. 使用對象

如果你的數據是對象,那么停止使用關系數據庫。編程界當前正在出現鍵-值對存儲的浪潮,它允許你以閃電般的速度訪問優雅的、自我包含的海量數據。沒有法律規定編寫Web應用的第一步必須安裝MySQL。對于對象的每一種表達方式都使用關系數據庫是一種過度使用,這也是近幾年SQL的名稱不太好的原因之一。事實上,問題在于偷懶的設計。

2. 在模型中使用SQL

編程中作任何事情都只有一種正確的方式,這是一種危險的說法。然而根據我的實踐,在面向對象的代碼中表達關系模型的最佳方法仍然是模型層:將你的所有數據表示封裝在一個單獨的區域是一個好注意。然而,記住模型層的工作簿在于表達對象,而在于回答問題。提供一個可以回答你的應用程序所包含的問題的API,盡量保持簡潔高效。有時候,這些回答顯得格格不入,以致于看上去是“錯誤的”,甚至對于資深的OO開發者也是如此。但是,你可以根據經驗來更好地找到其中的普遍性,從而允許你將多個查詢方法重構為單個。

類似的,有時候輸出會是單個對象X,它很容易表達。 但是也有時候輸出是聚合的對象表格,或者單個整數值。你要忍住將這些內容用過多抽象來包裝的誘惑,用對象自身的術語來描述。首要的是,不要相信OO能夠表達任何對象和所有對象。OO本身是一種優美和靈活的抽象,但關系數據在其范圍之外,把它不能表達的東西偽裝成對象是ORM的核心與真正的問題。

總結

  • ORM最初比編寫基于SQL的模型代碼更快,也更容易理解
  • 它在任何項目早期都是足夠有效的
  • 不幸的是,這些優點在項目復雜性提升的時候就消失了:抽象被打破,開發者被迫使用并理解SQL
  • 完全是非正式的聲明,我認為ORM對抽象的破壞不是僅僅涉及20%的項目,而是幾乎100%。
  • 對象并不足以充分表達關系查詢的結果。
  • 關系查詢映射到對象的不充分性導致了ORM后端應用的效率低下,這些問題普遍分布在應用的各處,并且除了完全放棄ORM之外,沒有簡單的解決辦法。
  • 不要對任何問題都使用關系存儲與ORM,而是更加仔細地思考你的設計
  • 如果你的數據天生就是對象,那么請使用對象存儲("NoSQL")。它們要比關系數據庫快得多。
  • 如果你的數據天生就是關系型的,那么關系數據庫帶來的開銷是值得的。
  • 把你的關系查詢封裝在模型層中,設計你的API從而為應用提供數據訪問支持;拒絕過分泛化的誘惑。
  • 面向對象無法以有效的形式表達關系數據;這是面向對象設計的一個基本限制,ORM無法修復它。

本文地址:http://www.snpmgr.live/librarys/veda/detail/2217,歡迎訪問原出處。

不打個分嗎?

轉載隨意,但請帶上本文地址:

http://www.snpmgr.live/librarys/veda/detail/2217

如果你認為這篇文章值得更多人閱讀,歡迎使用下面的分享功能。
小提示:您可以按快捷鍵 Ctrl + D,或點此 加入收藏

閱讀一百本計算機著作吧,少年

很多人覺得自己技術進步很慢,學習效率低,我覺得一個重要原因是看的書少了。多少是多呢?起碼得看3、4、5、6米吧。給個具體的數量,那就100本書吧。很多人知識結構不好而且不系統,因為在特定領域有一個足夠量的知識量+足夠良好的知識結構,系統化以后就足以應對大量未曾遇到過的問題。

奉勸自學者:構建特定領域的知識結構體系的路徑中再也沒有比學習該專業的專業課程更好的了。如果我的知識結構體系足以囊括面試官的大部分甚至吞并他的知識結構體系的話,讀到他言語中的一個詞我們就已經知道他要表達什么,我們可以讓他坐“上位”畢竟他是面試官,但是在知識結構體系以及心理上我們就居高臨下。

所以,閱讀一百本計算機著作吧,少年!

《UNIX環境高級編程(第2版)》 史蒂文斯 (作者), 拉戈 (作者), 尤晉元 (譯者), 張亞英 (譯者), 戚正偉 (譯者)

《UNIX環境高級編程(第2版)》是被譽為UNIX編程“圣經”的Advanced Programming in the UNIX Environment一書的更新版。在本書第1版出版后的十幾年中,UNIX行業已經有了巨大的變化,特別是影響UNIX編程接口的有關標準變化很大。本書在保持了前一版的風格的基礎上,根據最新的標準對內容進行了修訂和增補,反映了最新的技術發展。書中除了介紹UNIX文件和目錄、標準I/O庫、系統數據文件和信息、進程環境、進程控制、進程關系、信號、線程、線程控制、守護進程、各種I/O、進程間通信、網絡IPC、偽終端等方面的內容,還在此基礎上介紹了多個應用示例,包括如何創建數據庫函數庫以及如何與網絡打印機通信等。

更多計算機寶庫...

燃烧吧足球登陆