黃忠成

在Windows Azure所提供的Cloud Services服務裡主要分成兩種Role，一是許多人都熟知的Web Role，用於開發可Host於IIS的Web應用程式，例如ASP.NET及PHP等類。另一類是Worker Role，

用於開發不可Host於IIS的應用程式，例如自行開發的TCP Server或是Java/Node.js等類。

Proxy Pattern是Design Patterns中常用的一種設計模式，目的大致是隔離使用端及目標物件，降低使用端及目標物件的相依性，進而提升應用程式的可變性，也就是延展性。常見的Proxy應用大致如下圖。

delegate是C#的關鍵保留字，用來宣告可裝載函式的型別

Closure這種寫法，在程式語言領域存在已經有一段很長的時間了，其原意很簡單，就程式語言角度來看，Closure意指將一個function(函式)放到一個變數中，

也就是C++常用的function pointer(函式指標)的意思

ACS有個很有趣的機制，那就是ACS可以設定某個群組的Identity Providers為信任同盟，

隨著Windows Azure Platform的發展，其支援的平台及語言也越來越多，行動裝置自然也是重點之一，從去年開始，Windows Azure Toolkit for Windows Phone率先推出，
緊接著for iOS與Android版本也釋出了。10個月後的今天，這些Windows Azure Toolkits隨著Windows Azure Platform的發展逐步演進

在前些日子的Microsoft Developer Day 2012中，我主講一場『可攜性函式庫在Windows 8及Windows Phone 7開發實戰』，內容主要是談如何透過Portable Library開發類別庫，

使其能在不重新編譯情況下共用於Window Phone 7及Metro Style環境。

OK，一個全新的東西有何歷史可言？事實上，Windows Metadata本身並非是一個全新的東西，她最早的雛形

出現在.NET Framework 3.5 SP1，當初是為了Client Profile的目的而發明。

從2000年C#誕生以來，至今已經過了11年多了，C#的版本號也來到了4.0，在筆者所接觸的語言中，C#算是一個相當具有活力的程式語言，設計者Anders Hejlsberg的大膽且創新的特質充分的反映在這個語言上，

其每次的改版都會出現許多大膽的嘗試，目的是為了讓程式設計師能更快速、簡潔的運用C#來完成一些過去看來很複雜的動作，當然！所謂的大膽及創新的嘗試，通常也會引起正反兩面的意見。

本文列出一些C#中可以減少程式設計師撰寫程式碼數量的特色(語法、指令)，其中有些是大家已經耳熟能詳的

Framework最迷人的一點就是，設計時即考量到了延展性的議題，所以一個良好的Framework，必然擁有可擴充的設計存在，本文的Flow Engine雖然簡單,但也具備了這個特色。

Flow Engine，也就是我們常聽到的【流程引擎】，主要用途用於以特定順序執行一系列的工作，就概念上而言，Flow Engine非常簡單，只是依據特定順序來執行一系列工作而已

在ASP.NET 4.0中，有一個很有趣的特色：Pre Application Start Method，原本在ASP.NET中，當應用程式起始時首先被呼叫的是Global.asax中的Application_Start函式，新增的Pre Application Start Method機制

則稍微改變了這個流程，當某個Assembly標示了PreApplicationStar Method Attribute後，ASP.NET會在應用程式起始時呼叫指定的函式，這個動作發生在Global.asax中的Application_Start之前

切出Data Layout，通常是一個資料庫應用程式最初、也是最重要的部分，或許有些初學者對此感到困惑，是的!你可以用SqlDataSource做出客戶資料的編修畫面，

但一旦牽扯到商業邏輯，SqlDataSource絕對不會是選項，硬要使用的話會成為負擔。

想像一下，當設計訂單編修畫面時，你可以使用SqlDataSource來呈現訂單表頭及表身的編輯動作，但儲存前後庫存的控管就一定得回到ADO.NET處理，這時商業

邏輯便會呈現出與UI混雜的窘境，整個應用程式也會變得難以維護。

前一篇中，我們設計了GridViewHandler及FormViewHandler，讓商業邏輯可以由主程式中抽離，放置於外部來動態選擇要載入那些商業邏輯，就該例而言，這個設計除了將原本該

置於Data Layout的商業邏輯與UI扯上關聯外，其實並無其它設計較為不當之處，而將商業邏輯與UI扯上關聯這點，其實也是為了讓範例更加簡單易懂而特意設計的，要將這種設計

移置Data Layout裡也很簡單。

前一篇中，我們討論了Framework的觀念及設計時的注意事項，不過你我都明白，僅靠這些簡短的敘述，是不可能設計出Framework，更不用談實作部份了。

相對於撰寫應用程式，設計Framework通常需要更多的軟體架構及經驗，在看軟體架構的高度也與一般撰寫應用程式不同，通常設計Framework時，架構師必須要以很高的高度來看整個系統架構，然後逐步地往細節走，一開始，是看整棟大樓的位置，周邊，接著細看到每個房間的佈局，越往細節，所造出的限制就越多，這就是設計Framework的基礎觀念之一。

在2006年，我寫了一本[Windows Forms 框架設計實務]，書中淺略的介紹了Framework，也就是框架的觀念及設計概念，時至今日，算算也過了將近5年之久了，現在的Framework與當年我所專注的Framework雖然有一些差異，但在設計及概念基礎上還是一樣的，本文目的在於重新介紹這些概念，也介紹一些當年沒有出現的Framework觀念。

前篇文章所提及，目前Visual Studio Async CTP只能安裝在Visual Studio 2010英文版上，
原本想直接移除，但後來想起，Visual Studio 2010有個機制，允許我們將不同語言的版本裝在同一台電腦上，
所以當下放棄移除重灌的念頭，

在C# 4.0、VB.NET 2010時，C#的主要發明者Anders Hejisberg 宣布這兩個程式語言將進入Dynamic Programming的時代，以dynamic(C#)、Dim(VB.NET 2010)兩個宣告式開啟
了Dynamic Programming時代，從此之後，C#、VB.NET 2010在使用Automation(COM)及其他無法於編譯時期得知型別及成員函式為何時，能更加的簡單即快速來呼叫它們。
在PDC 10中，Anders再次宣告了另一個時代的來臨，C#及VB.NET將攜手進入Async Programming時代，在這個時代中，C#與VB.NET在使用非同步呼叫等相關函式時，將更加的簡便，
更加地趨近於同步呼叫模式。

...

多數的O/R Mapping Framework都有個共同的行為模式，在刪除資料或是修改資料前，必須隱式的下達一個Query，由資料庫取得即將要更新的資料列，
然後轉成物件後再更新。
這個行為模式，多半也會成為設計師考慮是否使用O/R Mapping Framework的考量之一，因為多一個Query，就代表著效能會因此降低