從資料結構+演算法分析ORM的末日

banq發表於2014-04-23
資料結構演算法ORM
大家討論都挺好，我下面進行純粹分析一下，今天腦子比較好些。

物件和資料庫都是一種靜態的資料結構，而SQL與LinQ或Lambda表示式或Stream都屬於一種動態演算法過程。兩個分別對應記憶體和CPU，如同哼哈二將，陰陽一體，一個系統由這個兩個組成比較和諧。但是有時會組合錯誤。

和諧：
資料結構+演算法過程

不匹配阻抗:
資料結構+資料結構
演算法過程+演算法過程

使用ORM相當於物件和資料庫兩個資料結構，因此存在阻抗矛盾，相反，因為SQL屬於演算法過程，SQL+資料庫反而比較協調，但是做些CRUD還可以，應對複雜的業務，需要翻看各種資料表設計才能明白業務，資料庫表又混雜了各種技術效能最佳化等技術方言，相當於方言夾帶普通話，只通普通話(代表業務語言)的人不容易聽通，增加溝通的難度。

後來有了Java等物件語言，就有了SQL+資料庫+DTO資料Java物件，這就是大部分系統的特點，兩個資料結構發生阻抗，改了資料庫表還要改Java物件。

Hibernate試圖協調物件和資料庫兩種資料結構矛盾，其實是清官難斷家務事，搗漿糊而已，因為從邏輯上物件和資料表兩者本來就沒有必要搞到一起，搞個對映對應。

Hibernate出來很討人喜歡，但是做些簡單CRUD沒有問題，隨著專案深入，加上程式設計師資料庫思維影響，使用Hibernate覺得隔著靴子瘙癢，其實我一直認為，如果程式設計師有閱讀一個框架的原始碼衝動時，說明抽象洩漏已經發生，洩漏出來的壞味道已經讓使用者心神不寧了。最終現實是：使用Hibernate的人是SQL與Hibernate兩個要一起掌握，其實是增加學習成本。

EventSourcing是因為DDD這個用物件分析複雜業務的方法出現以後才出來，ES屬於演算法，領域物件聚合根實體屬於資料結構，兩種陰陽搭配協調，如同SQL+資料庫一樣乾淨。

當然，LinQ+集合或Stream+Collection都屬於和諧乾淨的陰陽合體。OO+函式也是。包括大資料分析中Stream+Cache都是這樣。

總之：只要一個系統只有一個資料結構+一個演算法過程，這個系統本身就乾淨和諧，只有系統架構乾淨簡單，才不至於因為架構複雜而導致專案失敗或導致專案維護困難。聰明的人不能因為自己發明解決問題的方法干擾了自己解決問題的目的。

[該貼被banq於2014-04-23 07:37修改過]

相關文章