我們為什麼使用ORM?

部落格園在推廣ORM方面的確做了很大的貢獻，很多的程式員開始使用ORM，不用寫SQL的喜悅讓他們激動不已，可是好景不長，他們很快發現眾多的煩惱一個接一個的出現了。

很遺憾，我並不打算在這篇文章中解決這些問題，因為的確存在這些問題，而且目前沒有完美的解決方案。那麼既然這樣，我們為什麼要使用ORM呢？難道真的是為了不使用SQL嗎？

還是要看O - R ，我們為什麼要將關係型的資料轉化成Object的方式，DataSet的方式難道不好嗎？和資料庫的表現還是很一致，又簡單又方便，為什麼先輩們要興師動眾的轉化為Object。
我們知道，Object是可以繼承的，是可以使用介面的，而Relation沒有這個概念。就是因為這一點，我們將實體設計成Object方法，從而擷取了大量的優勢。
例如：我可以在程式中檢測實體是否支援IVersionObject介面，如果支援，我們將自動做版本控制，而如果你給我一個DataSet，那我將無法檢測（不要告訴我檢測是否存在Version欄位）。通過這個特性我們將可以自動化處理很多的事情。
又如，我設計了一個單據實體的基類，包含了SheetCode、SheetDate等等欄位，然後我的OrderSheet繼承自SheetBase，他們將自動擷取到這些標準的欄位，而且我的基礎類可以自動協助我處理很多統一的規則，使程式更加穩健和統一。而這個Relation的東西是非常難做到的。

市面上有很多的ORM系統，魚龍混雜，事實上，相當多的系統根本無法利用Object的繼承特性，他們還是一堆的如何做一對多、多對多的概念。根本沒有瞭解到ORM的精髓就做出來。

在這裡我需要解釋幾個誤解：
1、ORM使我們擺脫了SQL，但並不代表我們不再使用SQL，事實上，複雜的查詢和報表我仍然推薦使用SQL，良好的系統應該可以相容以前的方式；
2、微軟在表模型(Relation)上花費了無數的精力，所以目前Relation的一攬子解決方案是最完整，最好的。但我們看到，微軟在.NET 2.0中對Object方式的綁定支援更近了一步，隨著LinQ、XAML等很多後續技術的發展，相信領域模型(Object)的完整解決方案將更加完整；
3、ORM更適合複雜的系統（這裡使用複雜，而不是大型），而不是小的系統，因為這樣的系統要求建造速度快，系統穩定，他們的商務規則異常的複雜，但他們對系統的效能要求並不是很高（相對電信這樣的效能要求）。