在前幾篇文章中提到了Windows 8中核心之一的Language Projection,從一個簡化的角度來看,Language Projection位於語言、
編譯器與Windows Runtime Classes的中間,負責將兩者透過Windows Metadata黏合起來,大略如圖1所示。
Windows 8 – Bypass Language Projection with Native C++/WRL
- 12427
- 0
- Visual Studio
在前幾篇文章中提到了Windows 8中核心之一的Language Projection,從一個簡化的角度來看,Language Projection位於語言、
編譯器與Windows Runtime Classes的中間,負責將兩者透過Windows Metadata黏合起來,大略如圖1所示。
在前些日子的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的目的而發明。
在歷經兩個版本後,Windows 8來到了Release Preview階段,在穩定性及完整性上也更加的成熟,對於我而言,相對於全新的UI界面,
核心架構更能引起我注意
切出Data Layout,通常是一個資料庫應用程式最初、也是最重要的部分,或許有些初學者對此感到困惑,是的!你可以用SqlDataSource做出客戶資料的編修畫面,
但一旦牽扯到商業邏輯,SqlDataSource絕對不會是選項,硬要使用的話會成為負擔。
想像一下,當設計訂單編修畫面時,你可以使用SqlDataSource來呈現訂單表頭及表身的編輯動作,但儲存前後庫存的控管就一定得回到ADO.NET處理,這時商業
邏輯便會呈現出與UI混雜的窘境,整個應用程式也會變得難以維護。
前一篇中,我們設計了GridViewHandler及FormViewHandler,讓商業邏輯可以由主程式中抽離,放置於外部來動態選擇要載入那些商業邏輯,就該例而言,這個設計除了將原本該
置於Data Layout的商業邏輯與UI扯上關聯外,其實並無其它設計較為不當之處,而將商業邏輯與UI扯上關聯這點,其實也是為了讓範例更加簡單易懂而特意設計的,要將這種設計
移置Data Layout裡也很簡單。
在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來等待,前者會造成主程式的停滯,後者則會多使用一個執行緒,雖然還是有辦法來調整至完美,但還是需要一道手續。
當閱讀了dynamic型別有關的C# 4.0白皮書時,我很自然的想到了TDD(Test Diven Development),TDD原本意圖讓設計師在撰寫真正程式碼前撰寫測試碼,這個立意很好,因為大多數的設計師總是在完成程式後再來考慮撰寫測試碼,結果是測試碼永遠跟不上真正的程式碼,被放棄的機率高的嚇人。