小朱® 的技術隨手寫

在原理 (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 之間的互動複雜度就會成等比級數一樣。

[碎碎念] 參加 ITHome 第四屆鐵人賽的感想

在原理 (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 這些型別也時常出現，那麼要怎麼處理這些型別間的轉換？

Cloud Computing在2008年出現後，已經成為資訊產業的焦點領域，各大主流廠商無不投入雲端運算的領域中，台灣的主要軟硬體與系統商（趨勢科技、英業達等）也投入大量人力與資本到雲端運算的市場中，工研院也發展了自己的雲端作業系統Cloud OS 1.0進入雲端領域中，Google, Amazon與Microsoft更是不斷的擴充與強化自己的雲端運算實力，以吸引不同的產業與廠商進入雲端的世界。不過雲端運算的思維和一般應用程式有著極大的不同，若應用程式的開發人員無法理解雲端與一般應用程式的差異時，很容易設計出只使用雲端一點點資源的一般應用程式而已，完全無法發揮雲端運算的威力...

本文將會對雲端的安全議題做一概覽性的介紹，因為雲端運算會涉及的安全議題多且廣，所以無法太細部的介紹，如果對某些議題有興趣，可參考相關的資訊安全書籍。

早期企業在打造應用程式時，除了少數較宏觀的主導者以外，多數都是按照當下的需求以及業務條件來發展的，很少會有考量到軟體特性（例如Scalability、Extensibility、Maintainability等）的規劃。隨著時代的進步，物件導向程式設計與系統分析的發展，讓資訊產業開始重視軟體元件（Software Component）的概念，軟體元件的可重覆使用性愈高，則軟體元件的效益就會愈高，同時也代表該軟體的價值也愈高。但只要是在資訊產業涉足一段時間的人，通常都會知道資訊產業的主流總是掌握在幾個大廠商或是領導社群中，企業需要在不同的廠商標準間將內部所有的系統整併以維持或強化企業的資訊體質...

SQL Azure的資料庫應用程式開發和SQL Server有95%以上可相容，剩下的5%只要修改一下SQL，將不支援的指令移除後，一樣能連接SQL Azure。

SQL Azure的安全性可以分為兩個部份，一個是防火牆設定，另一個則是帳戶的管理與授權設定。

SQL Azure資料庫的管理，基本上多數功能和在本地的SQL Server是一樣的，但是和伺服器與作業系統調整的功能，就不在SQL Azure的支援範圍以內。

筆者之前在多場研討會和課程中講授SQL Azure時，都會強調一件事：『雖然SQL Azure和SQL Server很像，但它們本質上還是不同的』。看起來再怎麼像的東西，也一定有不同的地方，SQL Azure以Windows Azure基礎建設環境為基石建構，同時享有了高可用度與容錯能力，但是它並不是什麼都沒改就能做容錯的，除了基礎建設對網路與虛擬機器資源的支援外，SQL Server本身勢必也要做一些修改，才能符合SQL Azure原始設計上應有的功能。

在介紹完Windows Azure Platform基本的核心服務Compute Service, Storage Service, VM Role, Remote Desktop和VPN後，我們將焦點轉到資料庫上，微軟的SQL Azure是業界少數將關聯式資料庫（RDBMS）開放給外界使用的一種雲端資料庫服務（Cloud Database）...

雲端運算是一種新的資源整合方式，將雲端供應商的運算資源集中起來，並且利用使用者付費的精神將服務開放給使用者，使用者只需要付出很少的成本即可享有與大型企業對等的運算服務，在這個架構下發展自己的創意，並分享給所有使用智慧型裝置的用戶

Windows Azure Platform在v1.3時提供了一項功能，可以把Windows Azure Platform內運行中的虛擬機器當做企業網路中一台電腦的能力，就有如將外部電腦視為企業內網路的電腦一樣，這個新功能稱為Windows Azure Connect...

繼前一天的VM Role作業，我們已經成功的上傳了自訂的 VM Role 基礎作業系統影像 (base operating system image)，接下來就是在 Visual Studio 中使用這個VM Role。VM Role 和 Web Role/Worker Role 不同，它擁有自己的組態環境，不像 Web Role/Worker Role 是可以在上面建置專案，也就是說，企業的應用程式必須要在 VM Role 中都設定好以後，再將 VHD 上傳到 Windows Azure 資料中心。當然，你也可以使用 Remote Desktop Connection 的檔案上傳來傳送檔案，但是速度不會比直接在 VHD 組態好後再上傳來的快。

VM（Virtual Machine）Role 是微軟特別開放 Windows Azure Platform 上的 Image Deployment 機制，讓企業可以自行設定一個自己的虛擬磁碟（Virtual Hard Drive, VHD）並上傳到 Windows Azure Platform的 BLOB 儲存區中，而 Windows Azure Platform的RDFE (Red Dog Front-End) 可以在應用程式的設定下，由自己的 BLOB 儲存區中取用自訂的 VHD 進行組建，以作為應用程式的執行環境。

在今年九月的時候，收到來自於國外一間出版公司 Packt Publishing 的電子郵件，邀請我為他們的書 Microsoft Windows Azure Development Cookbook 寫篇書評，當時我原本是因為語言的關係回絕，但他們回覆說允許我使用繁體中文來撰寫，所以我就答應了，但因為很來事情實在太多，應接不暇，所以才拖到現在寫，對他們是有些抱歉 ...

Windows Azure Platform一開始的設計大多是以開發人員為中心，因為它是一個Cloud Platform，要先吸引開發人員的目光，才會讓它的應用變得更廣泛，但是雲端運算不是只有開發人員的任務，在應用程式發行之後，維運則是MIS與企業內的IT人員的工作，所以在1.3版開始，微軟慢慢的加入了與MIS維運有關的功能，其中一項就是Remote Desktop Connection（遠端桌面連線）。

開發雲端應用程式的思維可不能像平常開發應用程式一樣，我們每天在開發應用程式時，都能運用除錯器來偵錯，或是調台近端的主機上傳測試用，或是公司自己有自動化測試的機制，然而當應用程式上了雲端環境後，這些習慣幾乎通通不能用了，原因很簡單，雲端應用程式執行的地方可能是離你幾千公里外的公有雲機房，我們不可能在機房內掛除錯器偵錯，就算要上傳也要幾經思量（要錢），但是我們又希望能夠記錄或測量應用程式的執行細節，這時我們能夠用的，就是Windows Azure Platform本身的診斷服務（Diagnostics Service）。

Drive Storage是Windows Azure SDK特別為.NET的開發人員所準備的一個儲存格式，它只存在於Windows Azure SDK的組件和API中，它並沒有對外的REST APIs，除了使用Windows Azure SDK外，沒有別的方法可以使用，它本身是基於Page-BLOB為主的儲存服務，但將它模擬成一個獨立的磁碟機供應用程式使用...

學過資料結構的人一定都聽過Stack和Queue吧，Stack是後進先出（LIFO），而Queue則是先進先出（FIFO）的資料結構，商用系統的實務開發上，Queue的應用範圍比Stack要大的多了，因為在實務上會用到先進先出的案例太多了，舉凡線上訂位（購買）、抽號碼牌、選位等等商用的需求都會要求先進先出的條件，故Queue的應用範圍會比Stack大的多，微軟當然也很清楚這一點，所以在Storage中也實作了一個專門處理Queue的服務，即為Queue Storage。

SQL Azure Reporting 和 SQL Azure Data Sync 服務，簡直是難兄難弟，它們兩個都有一個共同的問題：CTP 很久，而且管理介面一開始並不好用也不怎麼開放，所以除了一些先導計畫的講師或專家會先進去用以外，大多數人看到那種介面就不會想用了 ... :) 還好，這次 PASS 大會也同時宣布了 SQL Azure Reporting 和 SQL Azure Data Sync 一樣也進入了 Final CTP 階段，不久後應該就會正式開始提供服務。

Table Storage是一個模擬關聯式資料庫的結構化資料（structured data）存取服務，它就像是在雲端中的表格一樣，允許應用程式可以在Table儲存體中宣告並存取自己的資料結構。而在Table儲存體的內部，則是橫跨多個伺服器與磁碟儲存區的基礎架構，微軟的Windows Azure開發小組將核心內的所有作業都隱藏起來，只顯露出一個REST API供外部應用程式存取，而且都是透過相同的URL來呼叫，因此Table基本上並不是儲存在應用程式所在的VM，而是在Windows Azure Platform內部自動規範的儲存區域中。

BLOB Storage顧名思義，是專門用來儲存二進位檔案使用的儲存服務，基本上檔案的格式沒有任何的限制，只要是可以轉換成二進位資料（binary data）的檔案都可以儲存，也就是我們常說的非結構化（unstructured）資料，舉凡一般的文字檔案到大型的影音檔案都可以使用。