接上篇《機房收費系統重構（一）》

二、概要設計

完成了用例圖，并用結合用例圖完善了一下需求分析說明書，忘記是第幾次修訂需求分析說明書。有了用例圖，很自然就進入了概要設計階段。我認為這一階段就是結合包圖解決系統的基本架構。在這里采用了三層架構（符合高內聚，低耦合的思想），并結合了一些設計模式。

?

下面看我的包圖：

可以看到，這個包圖，是從最經典的三層UI-BLL-DAL加入設計模式演化而來。

之所以采用抽象工廠模式是考慮到更換數據庫的方便。

而應用外觀模式，是為了解決UI層和BLL層耦合性過高的問題，UI層不必知道BLL層的存在，Facade（外觀）知道BLL層的哪些類負責處理哪些請求，它將UI的請求代理給適當的BLL層的類。使外部調用更方便。

?

三、抽象各層的類

當我們確定了整個系統的架構，接下來要做的就是細化，這是一個從宏觀到微觀的過程。

1、抽象實體類

我認為，第一步要做的就是抽象實體層的類（Entity），因為信息系統是對數據的操作和處理，首先必須要有數據，這個時候，我們要返回需求，了解用戶的數據要求，以此為依據進行數據庫設計，數據庫設計參見我的文章：

《數據庫設計第三范式》

還有一篇轉載《數據庫設計經驗談》

?

數據庫設計好了，我們要根據數據庫中的表抽象實體類，在機房收費系統中，實體類基本上是跟表一一對應的，一個表映射出一個實體類，表的字段即為實體類的屬性。

?

實體層并不屬于三層中的任何一層，它是獨立出來的一層，可以把他看做自定義變量的組合，供三層使用。

?

下面看看我抽象出的實體類：

見圖：

從圖中，看到有一個EN_PublicField類，這個類并不是由數據表映射而來，它是一個裝載公共變量的類，在系統中，盡量不要在類之外建立變量.有全局用的東西,我們可以建一個實體類,把該全局變量作為它的屬性。所以,實體類的數量可能多余表的數量.

?

2、數據訪問層

搞定了實體層，再來看看數據訪問層（DAL），這一層的主要任務是直接操作數據庫，完成對數據的增刪改查等。這里我們仍然根據數據表來抽象DAL層的類，基本上也是一個表對應一個類，這樣當我們增加新的表，直接增加新的DAL層類就可以，很好地符合了“開閉原則”。

另外，因為DAL層的類是直接對數據庫進行操作的類，所以這個類里封轉大都有四種方法：增刪改查。但根據實際情況會有不同的參數，不同的返回值。

?

這里加了一層接口，利用反射和抽象工廠，以防更換數據庫。見下面的部分截圖。

?

接口：

注：我們看到有一個接口叫ITime，這個接口是用來獲取服務器時間，所以DAL層類的數量也可能多余表的數量。

DAL實現IDAL接口

?

抽象工廠模式+反射+配置文件

3、封裝業務邏輯，構成BLL層的類

完成了數據訪問層，我們算是打好了地基了，下面我們再看用例圖，基本上一個用例封裝了一個功能。BLL層的類，我們可以根據功能來分，把與該功能相關的操作集成到一個BLL層的類里，這里我們要把握好粒度，平衡就好。

盡量做到符合單一職責原則，一個類完成一個功能，即不要在BLL層出現類之間互相調用的情況，雖然可以減少代碼量，但會增加系統的復雜性，造成模塊與模塊之間的強耦合。

舉個例子：“結賬”的時候我們需要查詢充值記錄表，“查詢充值記錄”的時候我們也需要查詢充值記錄表，我們應該在BLL層的結賬類里設置查詢方法，在查詢充值記錄類里也應設置查詢方法。

?

如果情況比較特殊，需要交叉調用，例如一個操作需要不斷的重復（超過三次），我們一般將它提取出來，供外部調用。這時候，我們應該把調用上移，即，不要在BLL類中調用BLL層類的方法，而是在BLL層的上一層，我們這里用到了外觀模式，所以在BLL的上一層即Facade層（見上面的包圖）完成對兩個類的方法的調用。

?

舉個例子："上機"需要檢查卡號是否存在,"下機"也需要檢查卡號是否存在，"充值"，"退卡","注冊卡"都需要檢查。這時候我們可以把檢查卡號這個操作提取出來。當我們調用的時候，不是在BLL層中直接調用，而是把它提升到Facade層來調用，即，調用上機之前，先調用"檢查卡是否存在"。

?

下面看看我的BLL層

在BLL層用到了策略模式：

4、降低UI和BLL的耦合，采用外觀模式，加入外觀（Facade）類

BLL層中有很多，很小的類，這就給UI層的調用帶來了困難，外觀類這一層為UI層提供了一個簡單的接口，大大降低了UI層和BLL層的耦合度，也可以看做是一次粒度上的粗化。

見圖：

5、界面層（UI）

界面層的類，就是我們的窗體類，有多少個窗體，UI層就有多少個類。

見圖：

三、設計模式

上面提到的設計模式有：抽象工廠模式，外觀模式，策略模式。在BLL層考慮使用模板方法模式。在UI層，將使用觀察者模式，實現狀態欄的動態變化。如果使用外部報表控件，很可能用到適配器模式。

?

總結：上述設計只是個人觀點，有待在編碼過程中驗證，歡迎拍磚。

轉載于:https://www.cnblogs.com/spring5/archive/2011/10/15/2485292.html

總結

以上是生活随笔為你收集整理的重构机房收费系统（二）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。