其他

在上一篇文章“.NET簡談組件程式設計之(上下文與同步域)

我假設看這篇文章的朋友對裝飾者模式都能有各自的、深入的理解。因為這篇文章是討論裝飾者模式的效能問題。在本人的“.NET簡談設計模式之(裝飾者模式)”一文中比較詳細的講解了裝飾者模式的一般應用，但是我總是感覺裝飾者模式隱隱約約之中有點不完美。經過我昨天一整天的思考、推敲終於找到了它隱隱約約中的那點不完美是什麼，為了行為去繼承帶來的無辜的效能開銷。所以本人想把它寫出來，跟大家討論下裝飾者模式的效能該如何平衡。是用時間換空間還是用空間換時間，這裡的時間就是我們開發的效率時間。首先回顧一下裝飾者模式誕生

我們繼續學習.NET多線程技術，這篇文章的內容可能有點複雜。在打破常理之後，換一種新的思考模型最為頭疼。這篇文章裡面會涉及到一些不太常見的概念，比如：上下文、同步域等等。我也是最近才接觸這些關於組件編程方面的高深技術，大家一起學習，再大的困難也是有時間限制的，只要我們堅持。在本人的上一篇文章“.NET簡談組件程式設計之(多線程與並發管理一)”中，只是初步的帶領我們學習一下關於多線程的一些基本的原理，包括線程切換，線程的開始、執行、等待、結束。這篇文章的重點是學習關於線程的同步、互斥的機制。在多線

我們都知道軟體發展經曆了很長一段路程，在軟體剛剛起步的時候，有一批世界頂尖的科學家用自己整個的人生為我們創造了今天美好的資訊世界，我印象最深的是我看過一本書，書名是《優雅人生》是專門介紹一位偉大的女性IT工作者，她是一位傳奇人物，她是編譯器的先驅，在她晚年的時候都拚命在一線開發環境中肩負著整個美國的IT重任，這位女性就是，格雷斯-霍珀；值得我們去敬仰，去學習；我為什麼要講上面的一段話呢，其實這源自於本人對技術強烈的慾望和興趣，尤其崇拜那些傳奇人物；在我們現在的軟體開發人員中很大一部分人沒有興趣去

大家好，今天這篇文章不是由我來跟大家講解什麼技術，而是我們一起來探討.NETFrameWork中的重要組件CLR的秘密，眾所周知CLR是所有Unmanaged

裝飾者模式其實有點難以理解，特別是對初學者來說可能有點暈，因為它的概念互相衝突，哪裡互相衝突我們下面會講解到。本人保持一貫的寫作風格，重在入門。在本人的這篇文章中會用一個比較恰當的比喻來讓我們對問題迎刃而解，例子雖然簡單但是重點突出。在寫這篇文章之前我在網上大概搜了一下關於“裝飾者模式”的一些文章，但是講解的效果都不太理想。要麼就是找書搬過來的，要麼就是對著書的例子從新創造一個。我看了大概三四篇這樣子，不行看著頭暈。文章的主人很想把問題的關鍵說清楚，但是很少能在原有代碼的基礎上畫龍點睛，搞不好就

其實C#的事件與委託在日常開發過程中不用也能解決問題，但是用於不用是不同的；更能體現出對象的高內聚、低耦合，兩個對象要想互操作，對外提供介面；甚至是讓另一個對象來處理本對象在發生指定事件的時候的操作；打個比方，我把自己比喻成一個對象，把飯店老闆比喻成另一個對象；這兩個對象是完全獨立的，我並不知道我要到哪家飯店吃飯，而同樣飯店老闆也不知道誰會來吃飯；如果不存在事件，我到了一家飯店，我跟老闆講我要吃飯，老闆不回話，我說我要吃白菜.....等等；都是我自己在操作過程，這樣太死板了，我不知道這家飯店是否

在我們日常開發過程中經常會遇到多個類執行個體之間的關聯，不管是B/S還是C/S的項目，在對執行個體的使用是一樣的；只不過C/S的項目比較好控制，不管是UI層的對象都能很好的控制，包括繼承、重寫等等；而在B/S裡面可能不太方便，由於B/S本身的特點，不能暴露內部太多的繼承關係，以免不小心破壞類的封閉性；我這篇文章主要是討論在多個類執行個體之間怎麼進行動態關聯，比如我們在開發Winform項目的時候，可能會碰到兩個或多個視窗之間協同工作的情況；本人在這種情況下採用的是靜態事件鏈的解決方案，多個執行個

互操作系列文章:.NET簡談互操作(一：開篇介紹).NET簡談互操作(二：先睹為快).NET簡談互操作(三：基礎知識之DllImport特性).NET簡談互操作(四：基礎知識之Dispose非託管記憶體).NET簡談互操作(五：基礎知識之Dynamic平台叫用).NET簡談互操作(六：基礎知識之提昇平台調用效能).NET簡談互操作(七：資料封送之介紹)我們繼續.NET互操作學習。本篇文章我們將來學習互操作基礎知識中的最後一個知識點“提昇平台調用的效能”；在於非託管函數進行互操作的過程中，由於涉及

提到分層，我就想起一句圖靈獎獲得者說過的話：電腦科學領域任何問題，都可以間接的通過添加一個中介層來解決；當初看到這句話的時候還不能深刻的體會到這句話的真正靈魂是什麼。之所以要寫這篇文章作為技術愛好者之一更願意與大家分享技術給我們帶來的快樂，本人將從另一個角度來解析.NET分層架構的真正奧秘。分層，一些技術功底比較薄弱的程式員聽到分層就會聯想到三層架構(BLL,DAL之類的)，其實不是，分層是一個很大的技術架構思想，三層架構只不過是對普通的資訊系統來說，將資訊的流轉通過三層來分解，在開發系統時一般

今天討論的問題可能會引起很多爭議，但我還是堅持做有爭議的敢說真話的人；軟考在很多各大高校裡還是比較流行的，只能說是流行而已，60%的人只是去湊熱鬧為國家軟考辦去做貢獻的，為什麼要說“每個程式員都應該經曆一次軟考”呢，這是源自於本人從軟考中得到的感悟吧，在園子裡很多人都是經曆過軟考的，有的人會說軟考沒有用，認證在找工作時根本配不上用場，不錯，這點我堅決認同，企業不會因為你得了個什麼軟考認證而另眼相看你，覺的你有多厲害；其實我們今天要探討的軟考的真正的意思不在於結果怎麼樣，就拿我自己來講吧，軟考其實

文章目錄 1. 為什麼我們需要基於RBAC模型的通用企業許可權管理系統2. 我們需要瞭解哪些知識點3. 我們怎麼設計基於RBAC模型的通用企業許可權管理系統4. 優缺點 1.

互操作系列文章:.NET簡談互操作(一：開篇介紹).NET簡談互操作(二：先睹為快).NET簡談互操作(三：基礎知識之DllImport特性).NET簡談互操作(四：基礎知識之Dispose非託管記憶體).NET簡談互操作(五：基礎知識之Dynamic平台叫用).NET簡談互操作(六：基礎知識之提昇平台調用效能).NET簡談互操作(七：資料封送之介紹)我們繼續.NET互操作學習。互操作的基礎知識已經差不多完了，當然一篇小小的文章很難全面的講述互操作的方方面面，本人只是總結出關鍵的地方好讓我們能入

說起資料提供者大家都不陌生，資料提供者的作用就是以統一的介面去訪問不同的資料來源，如OledbProvider、SqlServerProvider、OrcaleProvider等等；不同資料來源的訪問其實是不一樣的，微軟資料來源的訪問方式從ODBC到ADO.NET經曆了很多路程，各大資料來源供應商，都在不斷的生產不同結構的資料庫，為了以統一的介面去訪問各種不同的資料來源，微軟的.NET為我們提供了ADO.NET，我們通過ADO.NET可以很方便的訪問不同廠商生產的不同資料庫，ADO.NET也為後

在本人最近的幾篇關於交易處理的文章中，從交易處理的整體概念到具體的C#代碼的實踐操作基本上都已經能滿足日常的開發需求。文章中大部分的事務範圍類的操作都是局限於資料庫，在本人的“.NET簡談自訂事務資源管理員 ”一文中我雖然實現了一個簡單的自訂資源管理員，其實也能滿足基本的項目需求，核心功能也實現了，但是對於檔案事務操作我們是力不從心的。[王清培著作權，轉載請給出署名]從資料庫到自訂資源管理員都能參與到交易處理中來，在必要的時候保證資料的完整性，那麼我們缺一個類型的資源操作，當然您也許早就想問了，

提到指令碼，大家都耳熟能詳但是默默無私奉獻的指令碼引擎都被大家所忽略，本人也是最近才開始接觸指令碼引擎的技術的，是我的恩師指點我去學習它，

自從物件導向開發方式的出現，抽象的概念就開始日新月異的發展，物件導向編程、面向介面編程、面向組件編程等等；這一系列的概念都是軟體工程所追求的思想範疇，高類聚低耦合。今天我要簡談的是物件導向裡面非常重要的也是非常抽象的概念，介面。談起介面多少人曾經為之痛苦過，尤其是一些剛入門的開發人員(包括小弟)，百思不得其解，啥叫介面，介面能幹嘛用，用不用有什麼區別；等等問題困擾著，這些問題不解決不弄明白，很難在物件導向領域混，更別談物件導向開發了，可能有人認為物件導向開發就是麻煩我不用一樣也能開發，開發一個項

最近一直在忙新公司的基礎庫建設，對系統架構、開發架構及快速開發平台的設計實施都積累了一定的實踐經驗。一般的中小型的軟體開發公司，如果按照技術儲備來衡量軟體項目的技術含量的評定依據是可行的。但如果光是按照人頭來衡量軟體的技術含量是不可靠的。所以我們在選擇跳巢的時候是選擇大公司還是選擇有技術含量的公司要根據自己的職業規劃來。(本人最近體會到的一點跳巢經驗分享給大家)由於我現有單位技術部門剛剛成立不久，需要一些基礎的開發架構，ORM當然是跑不了的。在後面的文章中我將陸續寫下我在建設基礎架構中的一些實踐

在打算講這篇文章之前我深思一個下午，打算分兩篇來講的，但是又怕讀者看著嫌煩；其實稍微瞭解一點ActiveX外掛程式的朋友都能知道，這樣一扯可能出現一堆問題；但是我還是決定通過簡單的方式盡量讓初學者少接觸底層的東西包括OLE(對象串連與嵌入)、COM(元件物件模型)之類的概念，但是ActiveX外掛程式在開發上有很高的技術要求，雖然.NET為我們封裝了很好的實現途徑，但是我們也總不能停留在，知自然而不知其所以然的層面上；今天這篇文章我大概構思了一下，我主要會由淺入深的去逐層的講解，對一些概念性的東

先給大家說聲不好意思，在本人的".net簡談分層架構思想(徹底分離每個層)"文章中由於缺乏範例程式碼，所以給大家理解帶來不便，小弟先賠禮；這篇文章我補充所有實現徹底分層的全部代碼。徹底分層的好處是能合理的分配各個人員的工作量，比如在我們某一個項目團隊裡面可能有的人偏向於UI設計開發，有的偏向於商務邏輯的編寫，熟悉公司核心業務的人可以不需要管UI層和業務層的實現方式，只要實現資料訪問層的代碼，供上層調用；在本人的一個項目裡面，為了能讓所有的實現徹底分離開發是技術的要求也是業務的要求，項目大概是這樣