1. Policy Injection Application Block 小發現...

    因為工作的關係,最近正在研究 Enterprise Library 裡整合的 Patterns & Practices 介紹的各式 Application Block... 撇開其它的發現,有個東西一定要提一下,就是 Policy Injection ...

    介紹文章我就不多說了,一樣網路一大堆,有興趣的可以看 MSDN 官方的說明。比較特別的是它的用法。當年剛開始研究 .NET 內建的 Role Based Security Control,才在讚嘆它的 code 寫起來真漂亮,只要加個 attribute, 就可以在 runtime 自動檢查呼叫時的身份是否滿足 attribute 的宣告,如下:

    CAS範例程式: [copy code]
    [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Supervisor")]public void Foo() {    // ... }
    
       1:  [PrincipalPermissionAttribute(SecurityAction.Demand, Role="Supervisor")]
    
       2:  public void Foo() {
    
       3:      // ... 
    
       4:  }
    

     

    不管你的 code 在那裡,只要呼叫這個 Foo method, 當時的身份 ( principal ) 如果不屬於 "Supervisor" 這個角色的話,就會引發 Security Exception... 當初看到這真是太棒了,我可以用宣告的方式來作安全控制,不需要在主程式裡加一堆囉哩叭唆的 code 來查權限...

    不過當我開始研究如何 "自定" 這個行為,除了加上自己的安全機制之外,想更進一步的加上 Log 或是其它的檢查... 我才發現跟本辦不到。因為... 這行為是直接在 CLR 裡支援的啊,我可以加上一堆自定的 Attribute 掛上去,但是呼叫時完全不會觸發我的 code ...

    之後研究過 AOP,發現 AOP 正是解決我這類問題的 Solution, 無奈那些 solution 都不大實際,就沒深入研究了。之後找到篇 MSDN 的文章,裡面提到 .NET Remoting 時,遠方會產生 Proxy, 同時 Client / Server 之間的溝通會介著中間傳輸層傳遞 IMessage 介面封裝的 message, 到另一端才會由 Proxy 解讀,然後用 Reflection 還原呼叫的動作... 利用 Proxy 在還原呼叫動作時,你就有機會插入你要的邏輯 (IMessageSink),做到跟上面例子類似的功能。

     

    還是很不實際啊啊啊啊,我沒事也不會去用 .NET Remoting 啊,用不到的話這招對我也沒啥用 (大錯特錯!! 當年的我真是太過自信了 :~~~~) ... 這事就一直擱著了,直到...

    最近在研究 Policy Injection Application Block 時,讓我看到了似曾相識的 code:

     

    Policy Injection Sample Code #1[copy code]
    [AuthorizationCallHandler("operation-name")]public void Deposit(decimal depositAmount){  balance += depositAmount;}
    
       1:  [AuthorizationCallHandler("operation-name")]
    
       2:  public void Deposit(decimal depositAmount)
    
       3:  {
    
       4:    balance += depositAmount;
    
       5:  }
    

     

     

    這段 CODE 跟前面 CAS 的範例作用差不多,一樣是在 method 被呼叫前作一次權限的檢查。不同的是 AuthorizationCallHandlerAttribute 是自定的 (由 Security Application Block 提供的),它的作用比 ROLE 更進一階,是直接檢查授權的。之間的差別就如同 windows 大家都知道把 USER 加入 Administrators 角色的話,"預設" 就可以做大部份的事,但是你要在某個有 ACL 的物件 (如 NTFS 的檔案) 拒絕 Administrators 的存取也是可行的。前面 CAS 的例子就只是判定你是不是某角色的人,而這例子則是判定某個授權的定義允不允許你執行。

    扯遠了,重點不在安全,重點是自定的 Code / Attribute 也可以這樣用啊! 由於我多年心裡的疑惑,挖出這段作法比研究 Policy Injection 更積極一點 (老闆對不起...) 哈哈,沒想到答案就在前文...

     

     

    它ㄨ的!! 原來只是在 Local 使用 .NET Remoting ...

     

     

    說穿了不值錢,你用的物件標上 Attribute 後,要透過它的建立方式 ( Create or Wrap ) 取得加料過的物件,再呼叫它就會有你預期的效果了。這加料過的物件,就是 System.Runtime.Remoting.Proxies.RealProxy 下的某類別啊啊啊啊... 意思是我拿這加料過的物件,就會透過 .NET Remoting 的方式去呼叫到我真正的物件,而 Policy Injection Application Block 正好就替我把我要作的動作給補上去...。

    雖然心裡有被擺了一道的感覺,不過它的 code 包裝的真漂亮啊... 除了 Create 的方式由原本的 new .ctor( ) 改成它的 Create( ... ) 之外,其它就通通一樣了。更猛的是它還提供了幾個真的很實用的 CallHandler (就是呼叫時會加料的動作啦):

    • Authorization Handler
    • Caching Handler
    • Exception Handling Handler
    • Logging Handler
    • Performance Counter Handler
    • Validation Handler
    • Custom Pipeline Handlers

    大部份的 Handlers 都望文生義,像是 Logging 就是呼叫時替你加一段 LOG,而 Performance Counter 則是呼叫時就替你戳一下 windows 內建的 performance counter, 讓你可以透過 performance monitor 看相關統計 (如你的 method 被呼叫過幾次... ),更神奇的是 Caching, 如果你的 method 跑的很慢,加上去之後甚至是 cache 裡已經有了上次的結果,這次呼叫就直接 return 了... (你還記得你寫過多少次資料不在 cache 內就 insert 進去的 code 嗎?) @_@

     

    如果你看這篇期望看到啥 Enterprise Library / Policy Injection Application Block 的深入介紹的話,很抱歉... 我還沒那本事,哈哈... 再過陣子研究出心得,可能會寫幾篇吧...。 這類文章如果你不介意看英文的,官方的說明還有 QuickStart 的範例就夠你看了,可以參考看看,我就不獻醜了...。 這篇純粹是為了這 AB 解除了我多年來的遺憾,特地留下篇記念用的... :D

    2008/11/18 .NET C# MSDN Tips 技術隨筆 有的沒的 物件導向

  2. 重生的 IBM ThinkPad X40 ...

    我自己用了快六年的 ThinkPad x31 掛掉了,又沒潑到水,送去 LENOVO 修理,就回我 "液體入侵" ... 換主機板要 NTD 26500 ... 錢太多才會修,因此就跟我姊ㄠ了她已經沒在用的 ThinkPad x40 來用用...

    X40 什麼都好,就是敗在它那顆 Hitachi 1.8" HDD 效能實在太爛... 拿到 X40 後就馬上重灌 XP,剛灌好後就用 HDTune 測一下這顆硬碟的鳥效能..

    HDTune_Benchmark_HITACHI_DK13FA-40B

     

    後來也很巧,經過一夜灌了堆必要的軟體跟工具之後,突然喀啦一聲,硬碟就再也不能用了 :~  上網找找有無硬碟可以買? 還真慘... 都是拆機或是二手,個人保固七天或是一個月的那種。Hitachi也停產了,除了容量有 60GB 的之外也沒別的選擇了。效能很鳥的硬碟,相對的 $$ 也不算便宜,害我考慮了半天...

    後來決定用 CF -> IDE 的轉卡,加上忍痛買了張 SanDisk Extreme IV 8GB CF 卡,也就是俗稱 "偽SSD" 的解決方案,裝好後好像完全換了台電腦似的,剛裝好的 XP PRO (原版光碟安裝的,沒有刪掉一堆內建的軟體跟服務),開機的 WINDOWS 光棒,跑不到一輪就進 WINDOWS 了 @_@,真是傻眼,效能的增進遠超過我的預期...

    雖然容量小了點,不過效能跟原本的 1.8" HDD 實在差太多了,不足的容量就再補張 16GB SD 卡撐著用。只要不裝啥大型檔案,一般的 OFFICE 文件還不成問題,用起來也還不錯! 原本慢到想扔掉的 X40 就這樣又活了過來 :D

     

    最後補上 SanDisk Extreme IV 8GB 的效能測試圖:

    HDTune_Benchmark_SanDisk SDCFX4-8192

    2008/11/06 敗家 有的沒的

  3. [RUN! PC] 2008 十一月號

    IMG_0208

    YA! 第四篇!! :D 還是一樣要先感謝一下編輯賞光,讓我有點空間寫些不一樣的東西。

     

    基本的執行緒相關的程式設計跟函式庫,講的差不多了,其實這些也沒什麼好寫的。接下來打算寫一些應用的模式,來談談有那些方法,那些設計方式才能夠有效的發揮多執行緒的優點。看了 .NET Framework 4.0 / Visual Studio 2010 的 ROADMAP,有一大部份的重點擺在平行處理,INTEL年底也要發表四核 + HT 的 CPU ( WINDOWS 會認為有八個處理器 ),軟硬體都備齊了,剩下的就是程式設計師的巧思了。

     

    其實之前貼過幾篇類似主題的文章,只是這次把它統合起來介紹一下。生產線模式,如果簡化後就是 [生產者消費者] 的模式,而把它徹底一點的應用,則是上回提到 [Stream Pipeline] ..

    這篇也是第一次在雜誌上嘗試說明比較偏設計概念的文章,實作比較少,很怕不合讀者的口味... 應該不會貼了就沒續篇了吧? :P 有買雜誌的記得讀者回函填一下,哈哈,也算是點鼓勵。這次範例程式也是 Console application (我不會寫太炫的程式 :P ),需要的可以點 [這裡] 下載!

    2008/11/04 RUN! PC 專欄文章 .NET RUN! PC 作品集 多執行緒 技術隨筆

  4. 該如何學好 "寫程式" #5. 善用 TRACE / ASSERT

    哈哈,這篇拖的夠久了 :P

    上篇扯太多,寫到一半寫不完就留到這篇了。寫出可靠的程式,這是軟體工程師的基本要求。上篇提到了 TRACE / ASSERT 的應用,來複習一下:

    TRACE: 原本是 C 的除錯用巨集,目的是用適合的方式輸出除錯用的訊息,用來跟一般的訊息輸出有所區別。因為用的是不同的方式輸出,可以很容易的統一關掉。隨著工具的進步,輸出的方式也越來越適合除錯,比如輸出到開發工具的除錯視窗,或是輸出成記錄檔等等。

    ASSERT: 也是除錯用巨集,它接受一個 bool 參數,輸入值為 TRUE 時一切正常,就像沒呼叫一樣,輸入 FALSE 則會中斷程式,或是輸出顯目的警告訊息。目的在於確保程式的每個步驟情況都如預料般的順利。

    這兩個東西從 C 的巨集,衍生出各種語言及環境都有各自的版本。它的目的很簡單,就是 [Writing Solid Code] 裡提到的:

    用同一套程式碼,同時維護兩個版本 (RELEASE / DEBUG),讓錯誤自動跑出來。

    2008/11/03 系列文章: 如何學好寫程式 .NET C# 作品集 專欄 技術隨筆 有的沒的 物件導向

  5. 也是 "生產者 & 消費者" ...

    IMG_3467 (Canon PowerShot G9)

    哈哈,貼一下家裡魚缸的照片... 家裡養的孔雀魚一直生就算了,無意間丟進來的一隻蝸牛,沒兩個月竟然也生了一堆,現在算算大概有四十隻吧 @_@,照片裡紅紅的都是...

    不過有了蝸牛 (消費者),把水裡的魚大便跟水藻都吃的乾乾淨淨的也不錯啦,以前每週要換一次水,現在偷懶撐久一點都無所謂了 :D

    2008/11/01 有的沒的