文章寫得比較淺顯（主要是個人水準有限），大家可以讀來消遣排磚。^^
第二篇 系統構架及分析
圖一：系統概要圖
系統采用單伺服器部署方案，在邏輯層次上劃分為四個子系統，分别是使用者界面（UI），搜尋（Search），查詢（Query），資料（Data）。圖中箭頭的方向表示依賴的方向，即資料子系統依賴于搜尋和查詢子系統，使用者界面依賴于搜尋、查詢和資料子系統。其中資料子系統主要是通過實作搜尋子系統的ISearchDataService和查詢子系統的IQueryDataServicre兩個接口來對整個系統提供服務。而UI作為整個系統的驅動方。
一下我們來具體看一下每一個子系統：
一、 Search子系統：負責通路Ftp伺服器，給出伺服器上的檔案資訊。
二、 Query子系統：定義了檢索邏輯。
三、 Data子系統：主要是處理資料的儲存和實作資料的檢索。這個子系統直接和資料庫及索引打交道。其中資料庫類似于一個資源，儲存從網上擷取的原始資料，而索引則用于到資料的快速檢索、排序、分頁。設計中資料庫采用MS SQLServer 2000。索引程式使用DotLucene開源項目。
四、 UI子系統：包括驅動整個系統的驅動程式、系統運作的螢幕、日志、WebSite、WebService等。
然後我們再來看一下更詳細的包設計圖：
圖二：系統包設計圖
上圖基本上是圖一的細化。我們作一下分析：
1， Kernel包封裝了系統對真實世界的映射，其主要内容包含FtpItem及其派生類FtpFile，FtpDir。還是用于表示伺服器的Server類。所有的包都依賴于上述類。同時上述類是對真實世界的映射，是穩定的，不容易改變的，是以被依賴是正确的。
2， SearchBusiness包定義了搜尋邏輯，主要包括IRobot，ISearchDataService等接口，以及FtpException及其派生類，各種事件等。顯然這些類描述了系統用于搜尋的業務邏輯。是系統搜尋功能的核心。這個包不依賴于任何類，它規定了系統的行為，其他包依賴于此包，實作定義與此包得系統的行為。QueryBusiness包于此包的作用相同。
3， DataAccess包隐藏了所有的資料存儲和檢索的細節，對于外部程式而言，隻通過ISearchDataService和IQueryDataServicre兩個接口與該部分打交道，實作資料的存儲和檢索。同時該包使用了ADO.Net和DotLucene，用于具體的操作。
4， SearchFacade和QueryFacade對外部隐藏了搜尋和檢索的具體細節，給出了統一的通路接口（類似API）
5， 對于第三方元件EdtFtpNet的調用，采用了代理模式進行封裝。類似的，屬于UI的SearchApplication中，計劃采用Log4Net作為日志，也應該用代理模式進行封裝。
從以上的設計中我們可以總結一下幾條：
1， 細節依賴邏輯、實作依賴抽象。業務邏輯才是我們系統真正的核心。系統的行為是關鍵。用《靈活軟體開發——原則、模式與實踐》中的一句話說就是：“客戶給我們錢，是要我們描述系統的行為。”
2， 依賴應該向穩定的方向進行。接口、抽象類、對現實世界的映射類，這些類是穩定的；業務邏輯是穩定的，依賴的方向應該向這些項目進行。
3， 盡量解耦合。比如接觸資料子系統與業務邏輯的耦合、UI與具體的行為類的耦合等。從測試的角度來講，我們完全可以在沒有Data子系統的情況下測試Search和Query。僅僅構造一個實作接口的Mock類就可以了。
4， 對于第三方元件一定要封裝。這是常識，一個是為了版權上的問題，另一個是為了解除系統對第三方組建的依賴，使對第三方元件的使用依賴于系統。
大體的構架就是這個樣子了，但其實還很不完善。許多細節要到真正編碼中才能發現。代碼本身就是設計，對構架也有反作用力。構架也是在不斷演化中的。
以後我會繼續不斷地将系統的實作過程寫成文章，與大家共享。
本文轉自冬冬部落格園部落格，原文連結：http://www.cnblogs.com/yuandong/archive/2006/06/30/439964.html，如需轉載請自行聯系原作者