.NET Walker

Storage Queue是相對Service Bus而言較為簡單便宜的queue解決方案，以Storage為儲存體，在Storage中就可以直接建立: 透過程式碼操作的方式也很簡單，先找到key: 接著透過SDK，建立一個QueueClient物件即可操作: public static void CreateQueueClient ( string queueName ) { // Get the connection string from app settings string connectionString = ConfigurationManager . AppSettings [ "StorageConnectionString" ] ; // Instantiate a QueueClient which will be used to create and manipulate the queue QueueClient queueClient = new QueueClient ( connectionString , queueName ) ; } 請注意上面的程式碼使用了 Azure.Storage.Queues 套件，因此你必須從nuget安裝: dotnet add package Azure.Storage.Queues 我在github上有一個範例，讀者可以在建立好queue之後，透過git clone下載該範例運行: git clone https://github.com/isdaviddong/az204-DemoAzureStorageQueue.git 運行的流程請看底下展示影片: 身為一個簡簡單單的FIFO容器，Queue看起來沒啥大錄用，不過就是放放資料讓資料排隊慢慢處理，但記得前面提過的 Load Leveling嗎: (from Microsoft architecture center) 如果用的好，Queue可以幫你省下大筆 做 scale out的經費呢，總有人覺得雲端貴，但其實，往往...

古時候的應用程式，大多是一座孤島，作業系統載入一個應用程式(例如計算薪資)，當它運行完畢，結束，就退出作業系統，釋放資源，把控制權交出來。當時的應用程式架構很簡單，就…把功能通通寫在一起，完畢。 時間快轉到今年，過去就表過不提，自從有了網路(特別是網際網路)之後，應用程式的架構開始愈來愈複雜。例如，現在很多Web應用程式是前後端分離的架構，後端採用Restful API，前端運行在瀏覽器上，透過javaScript(或某種js框架)，與後端Restful API互動，彼此交互以完成一個工作。 這是近代初學者，最常碰到的應用程式架構。 但當應用程式的功能愈來愈多，我們當然不可能(也不需要)在『一個』應用程式當中，一口氣去完成所有功能，我們可以把應用程式切小，然後透過應用程式和應用程式之間的合作，來完成一個比較大的任務，這時候，擔任應用程式與應用程式之間資訊傳遞橋梁的事件(event)和訊息(message)就顯得非常重要了。 事件(Event)和訊息(Message)的意義 在這一篇的討論當中，你看到的『事件』和『訊息』這兩個字眼，大多意味著某種資訊 --> 像是一組JSON資料、一個文檔、或是一個XML資訊、甚至，只是幾個bytes的字串。 總的來說，『事件和訊息』就是 應用程式A 傳遞給 應用程式B 的某種資訊，主要的用途是 溝通 。例如用戶在前端網頁上購物，產生了一筆訂單，這筆『訂單』就是一個訊息，Web的前台系統，會把這個訂單，傳遞給中台或後台的其他程式，來處理出貨、扣庫存、帳務處理…等動作(功能)。 你或許有一個疑問，為何不在前台網站系統用戶產生訂單的那一刻，就扣庫存和安排出貨呢? 技術上可以，但實務上常常不是這樣的。因為不是所有的系統都是一體的，企業的系統可能是分階段、分廠商開發的，甚至可能根本是外購不同廠商不同開發技術的系統拼裝起來的，所以系統和系統之間的溝通，並不一定會發生在同一個資料庫裏面。而且這麼設計，會把系統個體之間的相依性綁得太緊，導致以後牽一髮動全身。如果我們把每一個功能(購物網站、訂單、出貨、庫存、發票…等)都設計成獨立的系統，有各自獨立的資料庫(儲存體或資料表)，也都可以獨立運行，那在架構設計上，將會更加彈性和靈活(其實這也導致後來逐漸成形的微服務概念)。而這樣的設計，就會導致系統和系統之間，需要透過『訊息或事件』來...

Service Bus中文叫做服務匯流排，在使用 Service Bus 前，請先透過底下方式建立: 建立好 service bus 後，接著我們就可以透過程式碼來操作，昨天的文章中，我們提過可以透過 service bus 中的 queue機制，來做 load leveling 架構。至於如何存取 service bus, 我有參考az-204課程，寫好一個範例程式碼，位於github，你可以透過底下指令來下載: git clone https://github.com/isdaviddong/az204-ServiceBusLab.git 從 github上clone我寫好的範例之後，你可以替換其中的連線字串，並且透過azure portal在service bus中建立名稱為『az204-queue』的 queue，即可執行該範例進行測試: 從上面的展示中你可以看到，我們透過兩個console app，一個作為訊息(message)的發送方，一個作為接收方，成功地透過service bus的queue來傳遞訊息與溝通。 如此一來，你就可以實現先前我們介紹過的 queue-based load leveling等機制。

在 上一篇 我們談過了AOP的概念以及如何透過attribute來實作類AOP的機制之後，你一定會想，要說Infrastructure Logic最容易跟Business夾雜在一起的情境，莫過於try…catch了，任何Business Logic中夾雜著try…catch，都很容易造成程式碼的過度相依，我們是否可以透過前面學習到的概念，利用Attribute來處理Exception呢? 我們看底下這段Code: 上面這段程式碼和上一篇我們介紹時的一樣，唯一的差別是第13行我們多加了一個ExceptionNotify的Attribute，這個Attribute會讓Calculate()這個Method發生Exception之後，自動將Ecception的狀態寫入LogFileName指定的log.txt檔。而無須把這樣寫log的程式碼用try…catch的方式寫在Calculate()這個Method當中…怎麼實現的呢? 我們看ExceptionNotify這個Attribute: 我們只需要繼承 PolicyInjectionAttributeBase，建立一個自己的ExceptionNotify，並且override OnException(sender,e)這個Method，在其中進行我們想做的錯誤處理即可。 如此一來，當掛上該Attribute的Method發生Exception時，就會觸發你在OnException中寫的code，將Log儲存到LogFileName所指定的檔案位置了: 如此一來，就再也不需要把處理例外的程式碼雜亂的混入Business Logic程式碼中了，不失為降低相依性的一個好方法。 完整程式碼可以參考: https://github.com/isdaviddong/isRock.Framework.AOP-Examples ----------------- 相關教育訓練: http://www.studyhost.tw/NewCourses/Architecture 若這篇文章對您有所幫助，請點選 這裡 加入FaceBook專頁按讚並追蹤，也歡迎您幫我們分享出去，謝謝您的支持。

這系列的上一篇居然是2013年…沒說錯，是2013，四年前!!! MS Enterprise Library 6.0(一) - Unity Application Block MS Enterprise Library 6.0 (二) - Logging Application Block MS Enterprise Library 6.0 (三) - Exception Handling Application Block MS Enterprise Library 6.0 (四) - Policy Injection Application Block 說真的，如果不是因為開了課，我根本早忘記我曾經寫過上面這幾篇文章。 上週六，是『 團隊開發 與 架構設計 實務 』這個課程的第二天上課，在課程中我們談到了一個框架設計上我常用的技巧，也就是如何透過Attribute來實作AOP(嚴格說起來是廣義的AOP)。如果你不確定明白AOP(Aspect-Oriented Programming)的基本概念，可以參考四年前的 這篇 。(天啊，四年前…) 課程中，我做了一個範例(具體內容後面說)，和某位學員討論的時候，突然看到學員的螢幕上出現了一篇看似有點眼熟的文章，語氣跟我好像…咦? 作者怎麼是我？是了，就是剛才說的四年前寫的 那篇 ， 這篇 文章中介紹了PIAB(policy injection application block)，這是當年我在Tech Days介紹MS Enterprise Library時，特別喜愛的一個application block，它很精采的把Business Logic和Infrastructure Logic做一個非常有效的切割，達成cross-cutting concerns的獨立性。 這一系列的文章或許是因為點擊率不很高，也或者是當時有別的事情再忙…我寫著寫著居然就忘了…也因此這個系列就沒了下文。時過境遷，這次上課的時候，我也不再介紹PIAB，因為這個PIAB Library的nuget套件很不爭氣的始終停留在2013年都沒更新，因此我們只能從底層架構說明透過Attribute實現AOP概念的作法。 不過這樣也好，學員可以從根本理解實現AOP可能的幾個方式 。然而，美中不足的是這樣去實現AOP的Method呼叫時，就得要有另一個Loa...

如果說 Unity Application Block 可以算得上是一份美味的佳餚，那 Policy Injection Application Block 絕對稱得上是開發人員最華麗的盛宴了。 要介紹Policy Injection Application Block之前，得提醒讀者，建議您先熟悉先前介紹過的 Exception Handling Application Block 以及 Logging Application Block ，因為我們待會要利用 Policy Injection Application Block 來作一個應用大集合。 首先，請你回憶一下Exception Handling Application Block，以及想像一下Exception Handling Application Block會怎麼用在你的系統中，以及怎麼幫助你以一個單一的例外處理模塊來管理你開發的系統的Exception... 不要偷懶，想像一下... ... ... ... ... ... 好，接著我們回到現實面，你會發現，我們前面說過，可以透過Exception Handling Application Block來管理例外，提供一個統一的方式來處理各種不同可能的例外...這樣很好，我們的系統透過這樣的設計，已經大幅的將耦合性降低，並且提高了重用性，這樣還有什麽讓人不滿意的地方呢? 有的，當程式碼愈趨鬆耦合時，我們開始看try...catch不太順眼。此話怎說??? 請看下面這塊典型的try...catcah: public void MethodA() { try { int a = 10, b = 0; a = a / b; } catch (Exception ex) { //以Config檔案中的 "Policy" ExceptionPolicy設定來處理 var rethrow = ExceptionPolicy.HandleException(ex, "Policy"); //如果設定檔說要重丟例外，就重丟 if (rethrow) throw; ...

有時候心情好，忍不住就多寫幾篇Blog。(當然，心情比較差的時候，可能十天半個月沒辦法安安靜靜的把一些東西整理出來) 前面錄了兩段 Enterprise Library 的介紹影片，分別談了 Unity Application Block 和 Logging Application Block ，這一篇緊接著談Exception Handling Application Block。 由於時空的限制，我現在所在的位置沒法錄製影片，所以只好乖乖用寫的了。 如果可以讓我選擇，我喜歡錄影片遠超過寫文字，原因很簡單，因為我話多，blog有時候忍不住就多寫了幾百字，但這年頭大家都不看字的，害我覺得寫了很無聊。寫了沒人看不打緊，花的時間很多，年紀大了越來越懶，用講的比較快，還可以當作上課的彩排甚至教材，所以我喜歡錄影遠超過寫文章。 岔題了。 Exception Handling Application Block，顧名思義就是系統中處裡例外的模塊，大家都知道，我們會在程式碼中加上try...catch來處理例外，程式碼常常會像是這樣: try { int a = 10, b = 0; a = a / b; Console.WriteLine("done!"); Console.ReadKey(); } catch (Exception ex) { //如果發生例外...就... } 這樣的程式碼沒啥太大的問題(除了因為是範例所以一定會發生例外之外...)。 但如果像上面這樣的程式碼一多，我們就會發現，每一個try...catch裡面都是另一段不受管理的複雜的錯誤處裡邏輯，可能是寫log、可能是發mail、可能是retry...，不僅如此，一旦例外處理區塊寫死之後，例外處理區塊常常本身就是一個大累贅。 還有，發生例外的可能性和類型很多元，上面這段程式碼非常簡單，只可能得到一個 "除以零" 錯誤...

Logging Application Block，其實是相當簡單的機制，基本上就是把紀錄Log這件事情，設計成一個獨立的模塊，讓開發人員可以方便重用。   而 Enterprise Library 當中，方便好用的地方在於，已經內建了多種Listener供開發人員使用，讓你將Log寫入各種不同的位置，諸如Event Log, File, DB, eMail...etc，如果有需要，您也可以自行繼承建立新的Listener，衍生出新的紀錄輸出位置。   要如何利用 Enterprise Library 中的Logging Application Block，輕易的在程式碼中透過單一的方式寫入Log，並且支援可隨時透過設定(不需要調整或修改程式碼)即可動態調整Log寫入位置，或增減各種不同的Log存放位置呢? 底下這段影片可提供您參考。 如果你的網速可以，建議以720p解析度觀賞: ( BTW, 如果你覺得我前面簡介Enterprise Library講得太囉嗦了，可以從 3:38 開始看Logging Application Block)    

開發人員在自己很辛苦的寫Code的同時，如果有時間，不妨多參考一些經典的套件或組件，從其中不僅可以學習到如何更快速有效的開發出中大型系統，同時間也可以參考前人的智慧，吸取他人的經驗，用來開發自己(公司)的套件或函式庫。 每每上課時，聽到開發人員撰寫代碼的重用率，幾乎都低到不行，即便專案的形似類似，卻常常重寫系統，不免有些感慨。如何能夠讓開發人員以更少的時間，完成更有價值的工作成果，實在是開發人員應該要關注的技巧。 底下這段影片，是答應學員要錄製的，內容來自我在今年(2013)Microsoft Techdays Taiwan研討會上介紹 Enterprise Library 的一個小片段，以一個具體的HR系統，薪資計算作為實例，來討論Unity Application Block的具體應用，當然，這個的背後就是IoC(Inversion of Control)與DI(Dependency Injection)的實現。 研討會中，總是用飆車的速度把原本要講超過半小時的東西，在5-10分鐘講完，對學員來說難免有些囫圇吞棗，導致吸收不良，有機會我盡可能把研討會中的內容，再整理成影片分享。 這段影片錄的不是很理想，甚至有些解釋不是很到位，但請原諒我時間真的不夠，沒能抽出時間再剪接修改(我的影片從來都是一次錄完，中間失敗了就整個重錄)，只好先以這個版本拋磚引玉一下，希望大家別介意。跟以前一樣，如果你覺得影片的內容對你有些幫助，就多一點分享給其他人，如果有需要改進的地方，請直接mail給我囉。  如果你的網速可以，建議以720p解析度觀賞: ( BTW, 如果你覺得我前面講得太囉嗦了，可以從 5:24 開始看實例 )