從Swift語言看ORM的定位錯誤

banq發表於2014-06-07
SwiftORM

Swift提供了資料結構struct和類Class兩種， 資料結構和類一樣支援行為，包括方法和初始化，資料結構和類的重要區別是：資料結構按複製方式傳遞，當你將一個資料結構傳遞給另外一個變數時，實際是複製了一份，但是類生成的物件進行傳遞時是按引用傳遞，傳遞的是那個物件的地址(當然地址值也是複製)。

Swift Struct程式碼如下： 

struct Card {
　var rank: Rank
　var suit: Suit
　func simpleDescription() -> String {
　　return "The \(rank.simpleDescription()) of \(suit.simpleDescription())"
　}
}
let threeOfSpades = Card(rank: .Three, suit: .Spades)
let threeOfSpadesDescription = threeOfSpades.simpleDescription()
<p>

Swift語言顯式地區分了資料結構struct和類Class，而在我們傳統語言中，包括Java C# Pthyon Ruby等基本都只有類Class一種物件模型。這就產生了問題。

這個問題我在從資料結構+演算法分析ORM的末日已經提到，資料表是一種資料結構，ORM框架是將資料結構轉為物件，其實這個物件是貧血物件，也就是隻有屬性或setter/getter而沒有其他業務行為的物件，如：

class Order{
   String orderId;
   Double money;
  ..
}
<p>

我們使用ORM，是將資料表order中的記錄拷貝到這個貧血物件Order中。實際上這個失血物件Order也是一種資料結構，只不過因為語言本身不支援資料結構，所以，我們借用型別Class的物件模型來作為資料結構物件，而且是對Class進行肢解的一種黑客方式（去除了其鮮明特徵：行為）。

現在有了Swift的struct，我們實際應該是將資料表order的數值複製到struct中，而且struct是按值傳遞的，如果你修改了原來的struct，其他複製的不會被改變。資料表實際是一個遠端的struct。

從以上分析看出，目前ORM框架包括JPA Hibernate Django Rails的ActiveRecord實際都定位錯誤了，將型別Class物件模型作為資料結構使用。

以前我們指出ORM末日主要是從抽象洩漏和效能角度提出問題，但是這些問題一般只是在專案複雜時才顯露出來，小專案反而體現ORM的快速的特點，但是我們從Swift這個新語言上看到，ORM方向搞錯了，應該是structRM才對啊。

ORM在未來面臨土崩瓦解，這個詞語會成為歷史名詞。

[該貼被banq於2014-06-07 09:05修改過]

相關文章