其他

動機 :在開發與資料庫溝通的系統時，因為建立資料庫聯機是比較昂貴的。 所以ADO.NET在背後幫開發人員，實做了 ConnectionPool的機制。 將系統內建立的資料庫聯機做快取，當系統要使用時就直接使用快取聯機，避免了每次都建立新資料庫聯機的花費。 並且實際上在使用ADO.NET時，開發人員對於背後的ConnectionPool機制其實是無感的。 要讓開發人員無感，可是又能完成快取的功能，這真的要花一點工夫去設計。 本文介紹一個『Singleton Pool模式』。

動機 : 一個軟體系統的生命週期，必然面臨到系統改版的問題。而在系統改版的時候，最常遇到的問題之一是，使用者希望增加系統對象的資料欄位(例如 :

 昨天跟朋友哈拉打屁，引發了一些想法 :「程式設計有分深度跟廣度」。 程式設計的深度，指的是技術背後的精神與實現。 程式設計的廣度，指的是技術工具的使用與應用。 當一個新技術發表，兩個不同角度的人一起去看。 最終的結果都是能掌握，但在的路途上卻是分歧的。 以ASP.NET MVC來說 : 從深度去看，看到的是。MVC的精神是甚麼、微軟怎麼實現MVC架構。 從廣度去看，看到的是。ASP.NET MVC有哪些方法可以用、在項目上怎麼應用。 這又延伸出了一個問題，一項技術該學到甚麼程度。 從深度去看，

動機 :前一篇  [Application Architecture] : Entity Expansion模式，介紹了一種擴充項物件屬性資料的模式。本文延續上一篇的動機，介紹一個Entity Profile模式。 Entity Profile模式主要是定義一組，資料對象(Entity)以及邊界對象(Repository)的產生、結構、行為模式，用來擴充項物件的屬性資料。實作這個模式，可以為系統加入增加式程式碼累積的能力。 基礎平台 : 結構 參與者Page

 前言 :一般說到應用程式架構 大家最容易聯想的應該就是「三層式體繫結構」 但筆者所要討論的應用程式架構 抽象邏輯上是架構在三層式體繫結構的上一層 針對軟體設計所規劃的應用程式架構 相關資料可以參考 : 微軟檔案「.NET 的應用程式架構：設計應用程式和服務」 本篇將焦點放在「資料存取層」 簡介 :所有的程式都離不開資料存取。 「資料存取層」所定義的就是將資料的存取，與應用程式的邏輯分開。 動機 :開發應用程式有時會遇到變更資料庫的需求， 例如將資料庫從SQL換到Oracle。 遇到這種問題

 前言 :說到「物件導向程式設計」跟「結構化導向程式設計」兩者之間的不同。常常會提到一點 :「物件導向程式設計程式碼比較容易重用」。 物件導向程式設計的前輩工程師，總結了很多經驗寫下了Design Patterns以及其他很多的資料文獻。 讓後續的工程師在重用程式碼的時候，有一些模式可以使用，而不用再去自己創造。 這大大增加了物件導向重用的機會，這類文章網路上已經有很多，這邊就不贅述。 本篇從廣義的抽象概念，來闡述物件導向的重用概念。 說明

 前言 :處理AD資料的時候 常常會需要取得使用者的Domain\User資料 可是使用者的AD屬性卻沒有這個資料 本篇文章的程式示範，如何取得使用者的Domain\User。 實作 :using System;using System.Collections.Generic;using System.Text;using System.DirectoryServices;using System.Security.Principal;namespace ConsoleApplication1{

接續...[Architecture Design] DDD經驗分享 (上) 系統分析階段 (SA)「系統分析階段」主要的工作是對客戶的需求內容，提出解決方案並且分析系統架構。一般會采UML的配置圖、套件圖等等工具，來完成系統分析的工作。最終將設計完畢的解決方案，整理成一份「系統需求規格書」。 系統分析階段要做的事很多很雜，甚至可以說是一種無中生有的創造過程。

動機 :Plugin是在軟體系統內增加功能的功能。 如果在軟體系統加入Plugin功能，能提高軟體系統的重用性。 加入Plugin功能的軟體系統在開發完成之後。 如果需要額外加入功能，不用變更已完成的軟體系統就能加入新功能。 並且因為不用變更已完成的軟體系統，也就避免了修改軟體系統會產生的風險。 在MVVM的架構下View跟ViewModel各自獨立，做Plugin功能也就變得比較複雜。 必須要View跟ViewModel各自都有Plugin功能然後再互相組合，才能完成MVVM

 『物件導向的架構』是怎麼樣的東西，今天忽然頓悟該如何用文字將他定義。 將在開發軟體項目的時候，遇到的各種不同功能面對象，歸類並取一個好記的名字。反覆重整功能面對象跟名詞，最終就會產生一個屬於自己的架構。 以DDD(Domain-Driven Design)的Domain

 前言 :繼承 是物件導向初學者，學完之後。覺得懂卻又有點模糊的東西 筆者試著用展開程式碼的方式，來解釋繼承的運作。 繼承 :底下是一段繼承的程式碼 這個程式碼很簡單，就是ClassB繼承ClassA而已namespace ConsoleApplication1 { public class ClassA { public void XXX() { // ClassA Code } private

 前言 : 我們在撰寫自訂 Configuration時，會先定義好對應的自訂 ConfigurationSection 與 Config檔讓程式碼知道該如何頗析資料。<sample propertyA="Clark001"> <propertyCollectionB> <add name="Clark002" value="Clark003" /> </propertyCollectionB>

前言 :上篇發表之後 朋友們的反應，大多是說太抽象了，好像啥都沒講。 其實觀念的東西真的就是抽象，本質真的就是簡單兩字而已。 呵呵~說的有點多了， 這第二篇主要是補充一個實作的例子， 看會不會比較那麼虛無飄渺嚕。 架構 :藍色框框代表一個獨立的DLL 特別標明出來是要傳達， 資料存取層的介面定義是跟邏輯層綁在一起的 資料存取層的實作成是是相依於邏輯層內的資料存取層介面 常常工程師在設計軟體的時候 會寫成 : 邏輯層==>資料存取層 建議的作法是 :

 實作 :1. 建立Windows應用程式項目  2. 建立資料對象 *建立完畢，先建置方案一次。  3. 建立資料來源  4. 建立報表  5. 繫結報表資料來源 *從右邊資料來源，拖曳資料欄位至報表  6. 建立報表表單 *選擇報表後會自動建立TestDataBindingSource 7. 建立報表資料  8. 撿視報表

 前言 :物件導向設計規則裡有一條：多用合成，少用繼承。 物件導向設計規則的內容可以參考， [深入淺出設計模式] : http://www.oreilly.com.tw/product_java.php?id=a163 本篇文章示範如何實作介面、抽象類別的抽象合成，讓合成之後的類別依然保有抽象方法。 使用時機 :當有一堆抽象類別，想要集合成一個大的抽象類別時使用。 例如說 現在要實作Facade這個模式 可是有些抽象對象的方法，要讓使用者去實作。 這個時候，抽象合成就可以派上用場。 結構

接續...[Architecture Design] DDD經驗分享 (中) 系統設計階段

 前言 :一般在監控檔案夾或是檔案異動，大多使用FileSystemWatcher類別 但FileSystemWatcher在監控檔案建立的事件時 他發出的 Created事件的時間點，是在檔案建立開始的當時，而不是檔案建立完畢的時間點。 如果直接使用的話，有時會造成建立檔案的線程跟監控檔案的線程互相衝突 造成『由於另一個進程正在使用檔案』的例外產生。 改為本篇文章介紹的使用方法及可避免上述問題 實作 :using System; using

 前言 :參加點部落的活動，關於IoC(控制反轉)大家有很多的討論。本文排除對象產生的部份，單純解釋IoC為甚麼叫做控制反轉。本篇文章以之前寫的 [Object-oriented] : 重用內容來舉例。 未IoC之前的對象圖 :很明顯的左邊的組件A，相依右邊的組件B。左邊的對象，相依右邊的對象public class Robot{ private Car _car = null; public Robot(Car car) { _car = car; }

 前言 :對象與類別 這兩個是物件導向初學者，很容易混淆的東西。 筆者試著從計算機物理層面，來解釋對象與類別的不同。 說明 :不管是物件導向程式或是結構化程式， 執行程式的時候。 電腦作的事情是 : 把執行檔案的檔案載入到記憶體並且一行一行執行。 載入到記憶體的檔案，這個我們姑且就叫他 : 「程式碼」 物件導向程式程式碼的單位，是以類別為單位。 也就是說，物件導向程式碼載入到記憶體裡面，我們可以把它看成一塊一塊的區段。 這個區段就是說我們常聽到的「類別」。 可以想象成這樣 :

撰寫多線程對象時，執行速度是一項很重要的設計考慮。通常為了加快執行速度，會將執行運作邏輯的主線程，跟發出事件的事件線程做隔離設計。這樣的隔離設計可以不讓主線程，因為外來事件處理而停頓。而這樣的設計下，為了簡化線程管理，可以採用ThreadPool來完成事件線程的工作。簡單的程式範例如下： namespace ConsoleApplication1{ class Program { static void Main(string[] args) {