資料庫開發過去與未來

前言

應用軟體的開發演進大約至少30多年了，30年可是一個漫長的過程，即使科技的進步神速，但對於商用軟體來說好像並不是這麼一回事；當然如果以資料庫來說，或許因為SQL的興起，讓應用軟體可以容納更多的資料與得到更快的回應速度，且讓資料的儲存穩定度也提升了不少；但如果是針對開發工具或開發語言來說，就很難斷言科技所帶來的是極大的便利與效能，畢竟20年前在DOS或Terminal時代開發效能也不一定比現在慢，為何會如此呢？主要是因為這20年來的作業系統變化很大，從文字模式到了圖形模式，又從圖形模式轉向網路與3D的介面，這個轉變，會讓整個應用軟體的開發模式發生了很大的變化，程式因為介面變得很複雜，因為觸發的事件處理，變得很容易出問題，當然，科技的進步是必要的，開發的模式與方法也是必須配合更新與提昇，只是事過境遷，總覺得過程中有過多的資源浪費與走過的冤枉路，對於開發的相關業者造成過多成本的浪費與經營的風險，確實是值得深思的話題。

資料庫的演變


如圖，我們可以從商用軟體的開發歷史，來了解整個演變的過程：

1. 資料檔的時代：這個時代想必還蠻值得大家懷念的，資料庫都是自己開發自行處理，格式自由，雖然資料庫都要自行處理，但不代表很麻煩，因為不管Cobol或C所寫的系統，對於資料檔有一定的處理能力，比較大的問題在效能與穩定度上，畢竟你要自行建立索引格式與維護是很容易出現問題的；如果大家還有記憶的話，當時出現了dBase這種簡單的資料庫(資料檔方式)，造就了當時商用軟體的蓬勃發展，簡易的關聯資料處理，已經讓大家樂翻天了。

2. SQL的時代：自從IBM推出了DB2之後，造就了RDBMS資料庫的風潮，從此資料庫就如同雨後春筍般風行市場，最後微軟也加入的戰局推出了MS-SQL後，將資料庫應用推向高峰，SQL型的資料庫系統幾乎是現今商用軟體的標準配備。主要還是資料庫提供快速且可靠的資料存取方案，加上ANIS-92制定的標準之後，更讓資料庫的地位屹立不搖，加上商用軟體對於資料庫過度的依賴，也讓SQL資料庫流行了20年至今還是主流的原因。

3. Entity的時代：由於近年來物件導向的風行，使得程式的開發都必須使用物件導向方式來開發，程式的架構既然如此，但反觀資料庫的架構卻不是物件導向架構，因此產生了格格不入的現象。前幾年，更有資料庫廠商提供了OODB的商品就是將資料庫與物件導向概念結合在一起，但在應用面上卻與傳統的RDBMS差距很大，讓開發者無法一時轉換過來，逐漸從市場上沒落了。後來又有人提出了O/R Mapping的觀念，將資料庫的Table以物件的方式來描述與對應，Table中取出的一筆資料，我們就稱之為Entity(一筆實體)，這樣就可以維持原來傳統資料庫原有的架構不變，又能以物件導向的方式來開發程式，對於熱衷物件導向的開發者是一大福音，也成為新時代下的開發主流。

.Net的資料介面演進

就拿.net來說，資料庫的介面也是慢慢演進的，如上圖，剛開始為ADO.net的方式，只是提供資料庫的連接方式，讓開發者可以直接以SQL語法來操作資料庫，並將取得的資料可以存放在DataSet中，當初的DataSet因為可以離線作業，而且可以保留狀態(如新增更改刪除的狀態)，所以成為多數.net系統的開發資料庫存取的主力；後來微軟在.NET 3.0中推出了LINQ的新語法，希望能取代SQL語法。為何要取代SQL語法呢？SQL有一個嚴重的缺點，就是要到了執行時才會知道語法是否正確，命令錯誤或欄位與Table不存在都無法在程式編譯過程中事先得知，因此，LINQ就是要將Table與欄位明確定義，透過編譯器能夠事先防錯，提升品質；另一方便LINQ也希望使用一套查詢語言來面對不同的資料庫(因為各家資料庫都有些微的差異)，更可以針對XML或DataSet甚至是Object內容來進行查詢，可惜的是，因為大大改變了程式開發人員的習慣，所以跟進的廠商與開發者並不是很多。

2009年微軟在.NET 3.5中推出Entity Framework，這是一個類似之前的O/R Mapping解決方案，它也將成為微軟跨越所有應用程式的資料整合技術方案，隨著VS2010與.NET 4.0的推出，Entity Framework更進展到了4.0 (跟著.NET版本走)，除了提供多項重大新功能外，微軟更宣佈EF將取代LINQ to SQL的發展，成為資料庫存取的主流技術。

何謂Entity Framework

全名應該是：ADO.NET Entity Framework，是微軟以 ADO.NET 為基礎所研發出來的類似ORM架構解決方案，前文中我們說過，ORM (Object-Relational Mapping )只是一個以物件導向的方式來存取資料庫欄位的架構而已，並非一個解決方案，如原來的ADO.NET只有資料庫連線，你只能下達SQL語法後才能知道是否有這個Table與這些欄位，很容易出錯，但在ORM的架構上，Table會強迫物件化，因此你改用物件導向的語法來存取欄位，更符合現代的開發模式與容易閱讀性。

但是，ORM也只能做到物件導向架構而已，從資料庫中取得資料與資料的維護
(Insert/Delete/Update)都必須自行封裝在這個ORM的Class中，因此微軟就在.NET 3.5之後將其擴充成為"解決方案"等級，除了透過EDM(Entity Data Model)自動化定義資料模型取代需要半人工定義的ORM Class之外，更重要的是已經可以自動幫你做到資料的讀取與維護等等，不必再自行下達SQL語句。更令人振奮的是無關資料庫的類型，不管你是MS-SQL還是ORALCE或其他資料庫等等，都可以用同一套元件與程式來處理，這樣對開發者來說確實是令人感到振奮的好消息。

Entity Framework的優缺點

首先說明優點，如下：

1. 符合物件導向原則：承如上面所說的，EF改良自ORM的架構，所以將Table封裝在EDM中，因此我們可以透過物件導向的語法來存取這些Table的欄位並且可以執行這些Table抽象後的方法(如Insert/Update/Delete/Query等)，這種開發模式是在編譯期可以發現錯誤或有問題的地方，不像傳統ADO開發，必須到了Runtime才發現錯誤，更符合現今的品質概念。

2. 隔離資料庫：因為開發過程中使用了Entity SQL或是LINQ，這樣可以透通在不同的資料庫間，不必因為資料庫不同，而造成程式必須改寫的命運.(當然必須配置不同的資料庫廠商所提供的Provider)。

3. 自動化的存取：因為EF已經不是一個簡單的ORM架構而已，Object Service層已經為你提供了Insert/Update/Delete的服務，當然是提供最基本的，複雜或困難的交易處理，也是要使用Entity SQL另外開發。

4. 更容易開發與維護：EDM的產生可以透過Visual Studio的工具以拖拉的方式來自動幫你產生，你可以不必自己建立，加上可以自動處理資料的SQL，會讓你開發資料庫軟體變得更輕鬆與省事。

5. 更好的效能：理論上，使用了EF架構後應該速度效能會變慢，因為多了一層EDM的轉換與分割，沒錯，但筆者說的效能，是因為他具有延遲載入的功能，如一開始的新增，你不必啟動後面的SQL去讀取資料，或是在Master/Detail間，當沒有處理到Detail時，可以不必預先去讀取Detail資料等等，針對關聯的外鍵資料(Foreign Keys)可以要使用時才去讀取等等，只要控制得宜，都會讓你具有一定的效能。

6. 更容易分層處理：早期使用ORM的架構最難的就是資料分層，在N-Tier架構上必須定義多份的Table Class，因為在N-Tier中並無法透通這些Class定義，造成開發上的困擾，但因為.NET 3.5以後的WCF (Windows Communication Foundation)支援了EF EDM的proxy class功能，讓分層的另一端也可以共用EDM內的class定義。

7. 更具未來性：目前包括WPF或Silverlight等微軟新的主流大都是以Entity為對象來呈現與操作，不再以ADO.NET的DataSet或DataTable的方式來處理，先不必說全部都轉過來，已不大可能這樣處理，但至少新開發的架構，可以使用EF來處理，另一個更好的好處就是，這麼強大的解決方案，是被放置在.NET 4.0中，你可以輕易的享受且免費使用。

因為以目前的Entity Framework架構來看，並非是完美無缺的，其缺點如下：

1. 未來性與持續性的疑慮：與LINQ類似，當微軟推出一項新的技術或方案時，並不是讓所有業者都可以放心跟進，畢竟有些時候需要一點勇氣與判斷力，當然，如果以目前Entity Framework的市場成熟度或許還不夠，但如果以技術成熟度來說，應該有一定的水準與評價，即使如此，還是有人抱著觀望的態度，畢竟現有的SQL方式還是可以用上一陣子。

2. 多層對應與批次處理的效能問題：畢竟Entity Framework須要透過EDMX來將資料實體對應到抽象的Entity上，其間都是必須面臨資料的多層存取轉換，一定沒有你自行以SQL操作來得便利與快速；相對的，如果你用大量的批次處理資料，以Entity Framework一筆一筆處理，其效能絕無法與一句SQL命令來得有效。

3. 無法100%滿足需求： Entity Framework並無法100%取代SQL語法，畢竟除了效能之外，還有一些特殊的資料處理也是Entity Framework很難或無法處理之處，因此還是有少數需求須要使用SQL的方式處理。

結語