小朱® 的技術隨手寫

ORM 很努力的幫你抽象化了資料存取的工作，但它並不會減少或免除你應該學習 SQL 的時間與必要性。

這絕對是 ORM 的使用者，開發人員與 DBAs 共同想要問的議題，到底我使用了 ORM 和使用傳統的 ADO.NET 下 SQL 指令的方式會差多少? 這個問題不但會發生在 Entity Framework 上，也會發生在 NHibernate 等 ORM Framework 內，連同我自己在這個系列文中開發的 ORM 機制也會受到影響...

ORM 原理前面8集中己經講述了基本的ORM核心內的運作方式，大多數的ORM其實都是這麼做，當然還會做一些更進一步的最佳化工作，例如產生SQL的方式等。不過既然都是寫程式的，當然會希望這些對應欄位的設定工作可以完全的程式化 (Coded Map)，而不用再假手那麼多的設定檔。

到原理 (8) 為止，我們已經完成了資料的查詢工作，但資料庫應用程式不是只有查資料而已，對資料的新增，修改和刪除 (C/R/U/D) 也要實作，才算是具有完整的資料存取能力，所以我們也必須要做到 C/U/D 才行，對程式來說，C/U/D 比 R 要簡單，但還是會有一些需要考量的地方，首先，在一堆資料的集合物件中，大部份的情況下不是每一筆都需要做 C/U/D，怎麼判斷每一個物件的狀態，以及在處理物件時何時更改狀態，就是一個重要的課題了，再者，如何產生資料庫需要的 INSERT/UPDATE 和 DELETE 指令，也是我們需要關心的。

在原理 (8) 中，我們展示了物件集合的處理與延遲載入，但忘了提到一件事，當延遲載入的物件要載入資料時要怎麼做。不過它的作法沒有特別困難，只是要產生一個有條件的 SQL 指令，並將傳回的資料填到物件內即可。

在原理 (7) 中，我們完成了關聯的基本處理，只是我們做到的是一對一的關聯，如果今天要的是一對多的關聯時，我們就需要處理到集合物件，集合物件不像單一物件那麼簡單，尤其是集合物件的元素又和其他物件有關聯時，載入的方式就會決定程式的速度，以我們到目前為止的例子，Customers, Orders 和 Employees 三個表格，Customers 會和 Orders 有一對多的關係，而 Orders 和 Customers 與 Employees 有一對一的關係，我們在原理 (7) 中實作的是 Order 類別，所以是一對一，但如果我們要實作 Customers 和 Orders 之間的關係，會變成一對多，也就是我們要處理 Customer 類別內的 OrderCollection 集合物件...

資料關聯 (data relation) 是 DBMS 的特色之一，它通常也是和物件難以整合的重要因素，因為物件的關聯和資料的關聯是不同的，物件的關聯是在物件內以屬性的方式連接另一個物件，但資料的關聯是在兩個表格之間以鍵值資料 (key) 串接，且 SQL 指令會透過 JOIN 指令 (不論是 INNER, OUTER 或 FULL) 來撈取關聯的資料，只是如果要在 ORM 內實作這樣的機制，勢必會有不小的難度，因為 JOIN 指令要由 ORM Framework 來產生，而且在取得關聯資料時，ORM Framework 未必會直接撈取關聯資料，而是在存取行為發生時才會實際填入資料 (又稱為延遲載入)，後者要判斷的事就更多了。

ORM 原理走到第六步，核心只會愈來愈複雜，但用戶端相對會變得簡單，會寫這一系列文的用意，是告訴大家 ORM 的核心大概的作法，像 NHibernate 或 Entity Framework，核心做法其實差不多，當然這些著名的 ORM Framework 一定沒那麼簡單，還有很多的配套功能要做，只是我想告訴大家的是，ORM 本身不會因為它看起來像物件就可當沒有 SQL 這回事，當物件存取和關聯愈來愈複雜的時候，Object 和 SQL 之間的互動複雜度就會成等比級數一樣。

在原理 (4) 中，我們使用了特徵項 (attribute) 來處理欄位對應的問題，只是這個方法對於可能時常異動欄位名稱，或是想要利用 copy/paste 以及擴大使用範圍的需求來說，可能就沒那麼恰當，因為使用特徵項最大的缺點就是：它是寫死 (hard-code) 的，若是想要修改欄位名稱的話，勢必又要重新 compile...

我們在原理 (1) 時，看到了看似很完美的屬性與欄位對應，因為屬性和欄位名稱一致，在處理起來算是很容易，但現實的情況是，屬性名稱未必會和欄位名稱一樣，這時我們就需要一套方法來處理欄位與屬性的對應。

我們在原理 (2) 中處理了許多內建的型別，不過還有幾種比較棘手的型別，其中一個就是列舉 (enumeration)，列舉也是一種實值型別，只是它大多用來作為限制常數的用途 (使用有意義的指令取代數字)，而且它不能用在泛型，所以 where 等於是不能用 (雖然有替代方案)。

我想大家或多或少都聽過 Entity Framework 或是 NHibernate Framework 這種大型應用程式開發的 Framework 吧，它們都是做 ORM (Object Relational Mapping) 技術的資料存取函式庫，只是很多人都只看它有什麼功能，卻沒有多少人對它內部感興趣－為什麼它們可以精確的對應 SQL 的欄位和物件屬性呢？我試著以一系列的文章來介紹 ORM 到底做了什麼事。

我們首先了解了 ORM 的繫結物件屬性與欄位時使用的方式，只是還有個問題，就是我們原先用的屬性型別都是 string，很好處理沒錯，但大多數的資料結構沒這麼簡單，一定不會只有 string 型別，像 int, double, long, char, boolean 這些型別也時常出現，那麼要怎麼處理這些型別間的轉換？