.NET Walker

AOP（Aspect-Oriented Programming，剖面導向程式設計）是一種軟體開發方法論，其主要目的是將商業邏輯(Business Logic)和橫切關注點（Cross-Cutting Concern, 例如 Logging, Permission , Exception Handling…etc.）分離出來，進而使系統更加職責清晰、易於維護和擴展。 在AOP中，橫切關注點被稱為切面（Aspect），切面是一種跨越多個物件和方法的模塊化程式碼，用來實現特定的橫切關注點。在AOP中，我們可以將切面應用(Apply)到一個或多個類或方法上，從而實現這些類或方法的橫切關注點。 AOP的主要概念是，若能將橫切關注點從主要商業邏輯(Business Logic)中分離出來，即可達到降低耦合、提高軟體重用性的效果。 舉例說明 首先來整理一下這個命題，我們知道AOP想把Business Logic和Infrastructure Logic做一個切割，達成cross-cutting concerns的獨立性，但這樣講很抽象，具體情境是什麼呢？ 看底下這一段code: using System ; namespace testAOP { class Program { static void Main ( string [ ] args ) { //建立BMIProcessor物件 BMIProcessor BMI = new BMIProcessor ( ) ; BMI . Height = 170 ; BMI . Weight = 70 ; //計算BMI var ret = BMI . Calculate ( ) ; //顯示 Console . WriteLine ( $ "BMI : {ret}" ) ; Console . WriteLine ( "Press any key for continui...

在 上一篇 我們談過了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; ...