黃忠成

從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，就代表著效能會因此降低

關聯式資料庫(RDBMS)，轉眼間已經陪伴了我們30幾年，也證明了它是近30年來最佳的資料儲存策略，但隨著雲端技術的來臨，這個老朋友卻遲遲未跟上腳步

Microsoft於日前釋出了Windows Azure Tools 1.2.......

在CPU進入多核心時代後，原本只限應用於高階多CPU電腦的平行運算技術，也因為多核心的平價化而逐漸浮現在家用電腦應用，什麼是平行運算呢？說穿了其實很簡單，就是依據CPU所內含的核心數，建立對應數量的執行緒，此時CPU的效能會發揮到極致，以2核心CPU為例，

圖18中有三個角色，Task Factory負責建立Task物件，Task Scheduler則負責Task的排程事宜。讀者們會覺得很奇怪，至今為止，我們建立Task的方式都是直接以new方式建立，其中並未見到Task Factory的蹤影呀？是的！這是因為Task類別的建構子預設會使用系統所產生的Task Factory物件，所以不需要設計師特別的傳入Task Factory或是明確的使用Task Factory來建立Task，以下是Task類別的模擬碼。

Task Library除了支援Planed/Un plan Exit時的例外處理，及Local Queue、Working Stealing機制外，還有一項很有趣的機制，那就是Continue With機制，這個機制允許設計師在一個執行緒結束後，緊接著安排另一個執行緒來執行指定的delegate，以較簡單、白話的說，就是執行緒的流程控管機制。

Thread Pool的出現，減輕了撰寫多執行緒應用程式時，所需承擔的執行緒過多而導致效能低落的風險，同時也透過重用執行緒來節省建立執行緒的時間，但是Thread Pool原始的設計仍然是太陽春了點，如前面所展示的，當我們需要等待多個Threads結束才做下一件事時，要嘛就使用Wait Handle在主程式等，要嘛就另外開一個執行緒，於內使用Wait Handle來等待，前者會造成主程式的停滯，後者則會多使用一個執行緒，雖然還是有辦法來調整至完美，但還是需要一道手續。

越是資深的程式設計師，對於運用到 Multi-Threading (多執行緒)的程式就越加謹慎，深怕一不小心就會埋下難以查覺的 BUG ，使用多執行緒就像是面對數匹脫疆野馬，一旦牠們開始跑後，你就很難控制牠們的走向，有些會順利到達終點，有些則會在途中出現意外。

看著一個程式語言的誕生，然後逐步追隨其成長，是一件相當有趣的事，特別是該程式語言一直都處於主流語言的時候，很可惜的，這種機會並不常有，C#是在我程式生涯中，唯一一個從其出生即跟隨至今的程式語言。在C#誕生之初，也是Anders Hejlsberg離開Borland之後的數年後