其他

我們繼續C#基礎知識的學習，這篇文章對前面基礎知識學習的朋友有著舉足輕重的作用；為了延續基礎知識學習的熱情，我編寫了這篇特殊的文章。本篇文章的中心是想借“.NET簡談反射(動態調用)”一文繼續發揮下去，讓朋友能一氣呵成，到底反射能用在什麼地方，究竟能起到多麼進階的作用。下面我就拿具體的例子講解，不廢話了請隨我來；1：必須具備的基礎知識C#介面：要想用反射進行高深的使用，必須先具備介面方面的基礎，只有用介面了才能是系統真真的活起來。參考.NET簡談介面

這篇文章主要介紹一下交易處理的本質。其實交易處理對我們來說並不陌生，但是很多人對交易處理的理解似乎有點弄不清，覺得交易處理只存在於資料庫中。導致這樣的結果是有原因的，當我們開始準備學習編程的時候，都是從某些程式設計語言開始學起，而不像人家的國外會先從概念、原理、模型開始學習，所以我們都會將某些技術與一些語言、平台聯絡在一起，導致我們學習其他的語言或者平台會很吃力。在學校裡也好還是自學也好，為了很快的上手都會去學習一些工具然後才會慢慢的去學習跟我們日常開發有關係的技術，僅僅是技術實現而不會去追根究

互操作系列文章:.NET簡談互操作(一：開篇介紹).NET簡談互操作(二：先睹為快).NET簡談互操作(三：基礎知識之DllImport特性).NET簡談互操作(四：基礎知識之釋放非託管記憶體).NET簡談互操作(五：基礎知識之Dynamic平台叫用).NET簡談互操作(六：基礎知識之提昇平台調用效能).NET簡談互操作(七：資料封送之介紹)本人最近在學習非託管C++互操作的技術，有點小收穫不敢私藏拿出來跟大家分享；作為.NET開發人員，我們有必要學習一些互操作方面的知識；尤其對一些進階程式員來

金庸的“天龍八部”我想我們都看過，最近心血來潮又看了一遍。喬峰的形象塑造的幾乎完美，我們都不會忘記他的“降龍十八掌”。在片中有各門各派、各種神奇武功，但是在我們眼裡最帥的、最厲害似乎還是喬峰的“降龍十八掌”。每當喬峰帶領大家遇到強大的敵人時，就會使出他的看家本領“降龍十八掌”來保護他的兄弟們。其實這篇文章本人是想將一些關於學技術的心理感悟寫出來，供大家分享。[王清培著作權，轉載請給出署名]時間過的真快，本人在.NET方向工作也快兩年了，在這不知不覺的成長過程中，我發現自己對技術的慾望越來越強，胃

本人寫部落格總是喜歡來一段開場白，其實細心看我文章的朋友能明白我的意思，本人就是想讓更多的人能理解我寫文章的用意，力求用通俗易懂的方式展現複雜抽象的概念，寫文章的朋友尤其是用心寫文章的朋友，其實真正的目的不是寫文章而是去協助大家學習技術，在.NET領域裡有各種各樣的技術，一個人的精力有限，在講解某一個技術要點的時候難免疏忽大意講錯，這很正常，我有時候在看一些前輩的文章時，總能發現前輩多麼希望將自己畢生的經驗、技術傳遞給每一個想學的人，他們是多麼讓我們敬佩，讓我們值得尊重，我還是那句話，技術不是用

也許文章的標題起的帶有諷刺的味道，其實這也是本人的一個小小的疑問。一個項目的領導者該不該對技術有一點深度的瞭解或者說專案經理應該是一個不錯的進階程式員。我的頭跟我說專案經理不需要寫代碼也不需要對技術有多瞭解，只要對項目的進度有個整體的把控就OK了。這種觀念一開始我不太贊同，專案經理對技術的實現沒有一定的瞭解，在安排進度的時候是不是會草率的了事。給程式員預留的時間也不能準確的控制好，是不是會導致項目的進度控制的不太合理；在參與開發項目的時候尤其是有一定技術含量的時候，更要專案經理對技術的實現有自己

我們繼續學習設計模式系列文章。今天要講的是單件模式，其實單件模式是比較簡單的設計模式，在我們日常開發過程中也是經常用到的。單件模式：單件模式是一種用於確保整個應用程式中只有一個類執行個體且這個執行個體所佔資源在整個應用程式中是共用時的程式設計方法。我想如果初學者對一些基本概念能熟練掌握時，其實單件模式是很簡單的，就是因為初學者對一些概念還不是很理解，我們先來掃除這些阻擋我們理解的障礙。大部分的初學者都會搞不清楚“靜態對象”與“執行個體對象”的區別。當然誰都有一個過渡期，不要急慢慢來，只要我們心平

觀察者模式想必搞程式開發的都聽說過，今天我也來簡單的總結一下本人在程式開發過程中是怎麼使用觀察者模式的；希望給大家帶來點新的想法，如果哪位高手看到了也不要嘲笑啊；呵呵，最求技術的人，始終都是為了技術而學技術，目的只有一個一起最求技術的最高境界；觀察者模式是設計模式裡經常被用到的一種，什麼叫觀察者模式，字面理解就是一個或多個對象觀察某個對象這種觀察是有目的地，當被觀察者發生某種事件時能準確的反饋到外界，通知大家你發生了什麼；尤其是在今天物件導向編程的不斷成熟，什麼都講究抽象將重複勞動省到最少，方法

互操作系列文章:.NET簡談互操作(一：開篇介紹).NET簡談互操作(二：先睹為快).NET簡談互操作(三：基礎知識之DllImport特性).NET簡談互操作(四：基礎知識之釋放非託管記憶體).NET簡談互操作(五：基礎知識之Dynamic平台叫用).NET簡談互操作(六：基礎知識之提昇平台調用效能).NET簡談互操作(七：資料封送之介紹)我們繼續.NET互操作學習，上一篇文章中我們介紹了Managed 程式碼怎麼與Unmanaged 程式碼C++之間的互操作；要想在Managed

我們繼續C#基礎知識的學習，這篇文章主要要講的是我們C#程式員邁向進階C#程式員的關鍵性的一步。有的朋友會說事實不是這樣的，我不用反射就不能開發嗎？當然可以，但是用與不用肯定是不一樣的，任何複雜抽象的分層架構或者說是複雜的設計模式均是建立在這些基礎之上的，比如我們要進行模組化、組件化開發，要嚴格的消除模組之間的耦合，要進行動態介面調用。這樣的強大而靈活的系統開發，必須要用反射才行；任何技術都有它存在的價值和意義，只要我們把它用在合適的位置就能發揮出驚人的力量；能儘可能的減少我們編寫的代碼，更能是

在本人的上一篇文章中只是簡單的介紹了一下.NETRemoting的一般概念和基本的使用。這篇文章我想通過自己的學習和理解將對.NETRemoting的整體的一個架構進行通俗的講解，其中最重要的就是通道(管道)處理模型思想，這裡面蘊含了很多的設計原理。[王清培著作權，轉載請給出署名].NETRemoting遠端架構是一個半成品，是.NET給我們的擴充架構，要想用於商業項目必須進行一些安全、效能方面的控制。要想進行一定深度的擴充那就要必須瞭解它的整體結構，各個點之間的關係才能很好的控制它。網上講解.

由於本人最近在工作中一直不太順利，不知道是自己的原因還是周圍的環境變化的原因；時間過的真快來公司快一年了，在這一年裡公司發展的飛快，開發人員比去年翻了近兩倍，公司的盈利據說也比上一年翻了許多；我們也為公司的發展而高興，畢竟我們也付出了許多，這付出是遠遠操作公司付給我們的報酬的，完全是來自自身的責任心，程式員絕大部分都是非常正直誠懇的，不玩虛的；好就是好，不好就是不好；不會看誰的臉色說NO；剛來公司的時候，壓力真大；連續加班一個月，每天晚上近11點到家，渾身累的不能動；有一次加班到11點多，去站牌

我們繼續學習設計模式系列文章。今天我們要學習的是設計模式中的適配器模式，適配器模式其實也比較好理解，光從它的名字我們都能理解個所以然了。適配器模式定義：將一個類的介面轉換成客戶希望的另外一個介面。適配器模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。上面的這段話可能對初學者來說有點抽象，短短的一段話提到了幾個關鍵的技術點。都是一些基本文法，如果我們還沒有掌握這些文法最好還是先去解決前提再來攻克設計模式。 那到底啥叫適配器模式，這個“適配”很形象、生動的形容了所表達的意思，那麼一般用

茫茫大海中，我們尋覓著，尋覓著那讓我們激動不已的技術，程式員不是尋覓著女朋友，而是尋覓著能陪伴終身的技術，我們做為程式員，有時候真的為自己的職業感到可悲，沒時間陪家人、沒時間逛街、沒時間聊天等等，我們把那些時間都用在了學習上，技術的道理上沒有終點站，只有一個個的裡程碑，今天的不學習，就註定明天被淘汰，其實今天我想要將自己的一些心理話說出來，讓我們程式員都能勇往直前，成為各個領域的技術專家，這樣才不會讓我們後悔當初所付出的寶貴時間；技術日新月異，從最早的DOS到今天微軟的Windows，我們作為微

今天跟大家分享一下本人在“.NET簡談構件系統開發模式”一文中提到的軟體架構設計思路的具體實現細節。大家看了我這篇文章後，總問我為什麼要起個這麼怪異的名字“構件”而不用“外掛程式”。其實這個名字在我腦子漂浮了很久，一直找不到合適的場合用它。在一本書上是這樣解釋構件的：構件是可以更換的組件，並且這個組件是由一系列很小的組件組成，同樣這些小的組件由更小的組件組成；我為什麼要區分外掛程式與構件主要原因是這兩個名字所表達的思想不同。外掛程式是可插、可卸的過程，沒有強調無限極的遞迴實現子外掛程式的意思，所

在本人的“.NET簡談組件程式設計之(初識遠程調用)  ”一文中，我們瞭解到什麼是遠程調用或者說在.NET平台上遠程調用是什麼樣子的，可能和偏低層(Socket\Rpc)的遠程調用有點距離。這隻是系統為我們封裝了假象而已，看不見不代表沒有這邏輯，是為我們減輕了勞動負擔。[王清培著作權，轉載請給出署名]這篇文章我們來簡單的瞭解一下在.NET平台上有一個強有力的遠程調用武器，也是上一篇文章中我一筆帶過的遠程英雄.NetRemoting。其實在.NET平台裡面到處都能看見Remoting的影子，只不過

互操作系列文章:.NET簡談互操作(一：開篇介紹).NET簡談互操作(二：先睹為快).NET簡談互操作(三：基礎知識之DllImport特性).NET簡談互操作(四：基礎知識之釋放非託管記憶體).NET簡談互操作(五：基礎知識之Dynamic平台叫用).NET簡談互操作(六：基礎知識之提昇平台調用效能).NET簡談互操作(七：資料封送之介紹)我們繼續.NET互操作學習，為了揭開互操作的神秘面紗，今天這篇文章我們就來先睹為快，讓我們先來做個例子，基礎的東西，我們陸續進行講解；由於互操作牽扯到的東西

我們繼續學習設計模式系列文章。本篇要講的是命令模式，其實命令模式也比較好理解，沒有用到多高深的技術，也不需要多複雜的抽象。只需要我們腦海裡能有一個大概的原型，等我們遇見類似問題的時候我們能通過巧妙的方式來解決。我們做應用程式層開發的大部分接觸的都是一些模式、架構、思想等等，不像搞低層開發的，他們研究的可能多數是一些技術實現的問題，而我們是學習實現的方法論。應用程式層開發在技術的複雜程度上是有限的，在組合技術的實現上是複雜的。所以有一些.NET架構師確實比較厲害，他們能很早的就料到會出現什麼問題，

我們繼續上一篇".NET實現之(WebBrowser資料擷取-基礎篇)"，由於時間關係這篇文未能及時編寫；上一篇文章發布後，得來了部分博友的反對意見，覺得這樣的文章沒有意義，WebBrowser採集資料效率低下用WebRequest效率就能提高了，本人不理解，為什麼同樣是HTTP協議進行資料擷取，效率能提高多少，在採集過程中同樣要經曆種種的高層協議向底層協議轉換等過程，我個人感覺WebRequest是實現更多的擴充性，本人的WebBrowser資料擷取，並不是談抓取資料的效率，重點是講解WebB

文章開頭本人申明一點，本人寫的文章力求讓看的人能理解精髓而不是專業化，部落格園的好多人在寫文章的時候總想著怎麼怎麼專業化，巴不得看的人都看不懂才能體現出他的技術，他的牛B，技術不是用來顯威風用的，在你掌握了某種技術的時候，不要想著橫掃部落格園之類的思想，有點技術就開始浮躁連說話都開始像李蓮英；我不是想這樣攻擊別人，在技術的這條路上大家能平易近人互相學習，以交流技術為主，不要想著看別人的文章就是在挑刺，想法設法打擊別人的信心，人無完人，人外有人，山外有山，各有所長，大家互補才能真正使我們國家的軟體