黃忠成

上一篇文章我們介紹了如何整合現有的JavaScript/CSS Framework到Electron應用程式裡，如果仔細看的話，你會發現Electron不管在HTML或是.js檔裡都是以Node.JS來編譯(當然，如果不喜歡的話也可以設定讓其使用JavaScript方式)，這也開啟了另一道門，整合現有的Node.js Framework/Component。

上一篇文章介紹了Electron的基礎應用，這次就讓我們一步步的朝實戰階段邁進，就架構而言，Electron最迷人的地方在於它可以直接套用網路上成千上萬的HTML/CSS UI套件，大幅的減少自行設計UI的工作，雖說如此，實際上在套用時還是有些需要注意的地方，幸運的是大多數會遭遇到的雷(問題)都差不多，也就是說你大概套個幾套後就掌握了8、9成的訣竅了。

寫程式這行很有趣，常常看到風水輪流轉的現象，近幾年來，前端技術不停地翻新，從一個Framework換到另一個Framework，從一個Pattern換到另一個Pattern，雖然聽起來很誇張，但如果深究一下，其根源JavaScript就是一個風水輪流轉的典範。規則鬆散曾經是他的致命傷，但到今天卻成了最大的優勢，Node.JS的誕生則加速了這個語言橫跨前後端的局勢，現在大概沒人會說，自己學的JavaScript Framework可以活幾年，因為，常常都是以月為單位的呀。

在前幾篇文章中提到了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界面，

核心架構更能引起我注意

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

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

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

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

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

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

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

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

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

移置Data Layout裡也很簡單。

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

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

在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 ，使用多執行緒就像是面對數匹脫疆野馬，一旦牠們開始跑後，你就很難控制牠們的走向，有些會順利到達終點，有些則會在途中出現意外。

當閱讀了dynamic型別有關的C# 4.0白皮書時，我很自然的想到了TDD(Test Diven Development)，TDD原本意圖讓設計師在撰寫真正程式碼前撰寫測試碼，這個立意很好，因為大多數的設計師總是在完成程式後再來考慮撰寫測試碼，結果是測試碼永遠跟不上真正的程式碼，被放棄的機率高的嚇人。