接上篇《機房收費系統(tǒng)重構(gòu)（一）》

二、概要設(shè)計

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

?

下面看我的包圖：

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

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

而應(yīng)用外觀模式，是為了解決UI層和BLL層耦合性過高的問題，UI層不必知道BLL層的存在，Facade（外觀）知道BLL層的哪些類負責(zé)處理哪些請求，它將UI的請求代理給適當?shù)?/span>BLL層的類。使外部調(diào)用更方便。

?

三、抽象各層的類

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

1、抽象實體類

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

《數(shù)據(jù)庫設(shè)計第三范式》

還有一篇轉(zhuǎn)載《數(shù)據(jù)庫設(shè)計經(jīng)驗談》

?

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

?

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

?

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

見圖：

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

?

2、數(shù)據(jù)訪問層

搞定了實體層，再來看看數(shù)據(jù)訪問層（DAL），這一層的主要任務(wù)是直接操作數(shù)據(jù)庫，完成對數(shù)據(jù)的增刪改查等。這里我們?nèi)匀桓鶕?jù)數(shù)據(jù)表來抽象DAL層的類，基本上也是一個表對應(yīng)一個類，這樣當我們增加新的表，直接增加新的DAL層類就可以，很好地符合了“開閉原則”。

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

?

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

?

接口：

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

DAL實現(xiàn)IDAL接口

?

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

3、封裝業(yè)務(wù)邏輯，構(gòu)成BLL層的類

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

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

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

?

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

?

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

?

下面看看我的BLL層

在BLL層用到了策略模式：

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

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

見圖：

5、界面層（UI）

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

見圖：

三、設(shè)計模式

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

?

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

轉(zhuǎn)載于:https://www.cnblogs.com/spring5/archive/2011/10/15/2485292.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。