EZTABLE IDEAS 是 EZTABLE 成員揮灑熱情和大家分享專業及創意的網誌。 EZTABLE 讓消費者 24 小時都可以在網路訂位全台灣最優質的餐廳,同時提供餐廳經營者 e 化的訂位管理系統 (雲端、iPad、智慧型手機)

Engineering: To ORM or Not to ORM

六月 22 2011 Published by under Engineering

ORM is an anti-pattern 這篇文章在最近引起了廣大的討論,以下為小弟歸納這篇文章的重點並加入一些自己的看法,有興趣的朋友強烈建議您閱讀原文。

 

Web開發者大概都有接觸過ORM(Object-relational mapping)的經驗,其中最有名的就是Java的Hibernate跟Ruby的ActiveRecord,大部分ORM的framework都宣稱有以下好處:

  • 不用再寫SQL,或是可以少寫很多SQL.
  • 自動產生CRUD functions.
  • 雖然效能上不如直接寫SQL (其實也沒有差很多),但是卻可以節省許多開發時間。

 

開始用一個ORM framework時,可以充分感受到以上這些好處,但是隨著時間經過,程式邏輯越來越複雜,我們越來越常做下面這些事情:

  • 思考如何把一個複雜的SQL query用ORM framework寫出來,有時候我們甚至必須多學一種語言 (如Hibernate的HQL),才能表達出正確的邏輯。
  • 不惜深入framework的底層,確認最後framework所轉換出來的行為,真的是我們要的。
  • 真的沒有辦法,只好直接寫SQL。

 

ORM有一些本質上的問題:

  • 不足夠的抽象化:一開始的Query都很簡單,就好像大多數Getting Started上的project一樣,然而,或許是邏輯本身就如此、或是為了跟舊的Code相容或是沒有時間做Refactoring,我們不可避免要做複雜的join,當複雜的join發生時,往往沒辦法用object/methods來表示這段邏輯。
  • 錯誤的抽象化:SQL是設計來回答問題,不是用來取出Object,當3個以上table彼此之間有不同關係時,若要用object來表示,要preload多少東西進memory這件事是無法被決定的。
  • 效能:當用ORM取的一個object時,即使我們只需要其中一個值,仍需要把整個row取出來。扣除掉那些真的沒寫好的SQL,如果所有的Query都慢一點點,那整體來說就慢了很多,

如果完全沒有碰過上面這些問題,代表資料之間也沒有複雜的關係,完全可以用Object表示,那麼使用NoSQL或許是更好的選擇,畢竟他比Relational database快上好多倍。

 

底該不該使用ORM?

如果你有一套熟悉的ORM framework,那就用吧!畢竟對於簡單的Database操作,用ORM真的能省下不少時間,以Python的Django framework為例,使用內建的ORM還可以連帶得到許多附加的功能。以學習的角度來說,了解一套ORM framework的internal對程式功力也有很大的幫助。

從開發產品的角度來說,如果沒有熟悉的framework,自己幫常用的SQL query模組化寫成model其實也不會慢多少,即使一開始使用ORM,隨著產品的演進,到最後也會逐漸替換掉。


麼用ORM?

如果確實使用MVC的架構,把ORM framework當成一種Library只用在Model裡,在初期和開發新功能時時可以省下很多時間,日後若要更換也只要改變model的實作方式即可,重點是讓model回答問題,而不是表現一個Object。

最後套用一句原文中的話:「OO is itself an abstraction, a beautiful and hugely flexible one, but relational data is one of its boundaries, and pretending objects can do something they can’t is the fundamental, root problem in all ORM.」

 

(Image via Serk 17, CC license)

 

York Tsai,

Software Architect @ EZTABLE



Related Posts Plugin for WordPress, Blogger...

No responses yet

發表迴響