【摘 要】在軟件開發(fā)過程中，面對不斷變化的系統(tǒng)性能需求，軟件系統(tǒng)往往過于脆弱和僵硬，不易維護(hù)，較難復(fù)用。在復(fù)雜的應(yīng)用系統(tǒng)中，比如基于Web Service系統(tǒng)的應(yīng)用中，如何使代碼良好地組織起來，封裝成類，將類組織成系統(tǒng)性的類庫，這都需要開發(fā)人員在高于對象這一層面上來把握整個系統(tǒng)，設(shè)計模式就滿足了這一需要。

【關(guān)鍵詞】設(shè)計模式；衛(wèi)生服務(wù)；數(shù)據(jù)庫

在軟件開發(fā)過程中，面對不斷變化的系統(tǒng)性能需求，軟件系統(tǒng)往往過于脆弱和僵硬，不易維護(hù)，較難復(fù)用。眾多軟件開發(fā)人員一直在不斷總結(jié)實踐經(jīng)驗，逐步形成了設(shè)計開發(fā)過程中的一種指導(dǎo)思想（即設(shè)計模式）。本文介紹通過社區(qū)衛(wèi)生服務(wù)系統(tǒng)的開發(fā)實例，具體說明了在.NET環(huán)境下Web系統(tǒng)中設(shè)計模式的選擇和運(yùn)用方法。

1.工廠模式應(yīng)用

1.1 工廠模式和抽象工廠模式概述

工廠模式的意圖是定義一個用于創(chuàng)建對象的接口，讓子類決定實例化哪一個類。抽象工廠模式的意圖是提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。

1.2 模式的運(yùn)用

在使用社區(qū)衛(wèi)生服務(wù)系統(tǒng)的過程中，衛(wèi)生局、醫(yī)院、社區(qū)衛(wèi)生服務(wù)中心/站三級間實現(xiàn)衛(wèi)生數(shù)據(jù)共享，但社區(qū)衛(wèi)生服務(wù)的門戶網(wǎng)站、社區(qū)衛(wèi)生服務(wù)系統(tǒng)中相關(guān)業(yè)務(wù)的操作卻要求使用不同的數(shù)據(jù)庫管理系統(tǒng)，比如Access、SQL Server。當(dāng)系統(tǒng)的規(guī)模發(fā)生變化時，采用的存儲手段就會發(fā)生相應(yīng)變化，這時需要修改涉及數(shù)據(jù)存取操作的所有模塊。如果我們假設(shè)都是采用數(shù)據(jù)庫存儲的，雖然不同的數(shù)據(jù)庫管理系統(tǒng)都是基于能夠使數(shù)據(jù)庫使用簡單的結(jié)構(gòu)化查詢語言，但在ADO.NET上的使用是不同的。在SQL Server上用的是System.Data.SqlClient命名空間下的SqlConnection、SqlCommand、SqlDataReader、SqlDataAdapter，而Access則要用System.Data.OleDb命名空間下的相應(yīng)對象。這樣不同的數(shù)據(jù)庫在實現(xiàn)細(xì)節(jié)上的區(qū)別，不同數(shù)據(jù)庫的替換給應(yīng)用程序的使用、創(chuàng)建帶來了一定的難度，并且潛在的創(chuàng)建了應(yīng)用程序代碼和數(shù)據(jù)訪問代碼之間的直接依賴性。

圖1 User表增加用戶結(jié)構(gòu)圖

如何在系統(tǒng)中爭對不同業(yè)務(wù)使用不同的數(shù)據(jù)庫，解除業(yè)務(wù)邏輯與具體數(shù)據(jù)庫訪問的耦合，工廠方法模式可以創(chuàng)建一個具體對象的接口，讓子類決定實例化哪一個類，它可以實現(xiàn)客戶不用了解哪個類要進(jìn)行實例化。工廠方法模式實現(xiàn)代碼（以User數(shù)據(jù)表中增加用戶為例）結(jié)構(gòu)圖見圖1。聲明IUser接口的對象事先不需要知道是在訪問數(shù)據(jù)庫，但在運(yùn)行時會很好地完成工作，實現(xiàn)業(yè)務(wù)邏輯與數(shù)據(jù)訪問的解耦。

但隨著更多數(shù)據(jù)提供者和輸出類型的增加，一個基于工廠模式的類模型將成倍的增長。比如上述數(shù)據(jù)庫中除User用戶表外還有部門表，因此工廠模式在處理多于一個參數(shù)的問題就比較困難。本社區(qū)衛(wèi)生服務(wù)系統(tǒng)的需求是要求系統(tǒng)能夠在兩種數(shù)據(jù)庫之中選擇一種數(shù)據(jù)庫訪問；系統(tǒng)數(shù)據(jù)的業(yè)務(wù)邏輯，即數(shù)據(jù)庫的基本操作（包括添加、刪除和修改等）僅具有行為而與數(shù)據(jù)無關(guān)。如果把具體的數(shù)據(jù)庫訪問看作一種“產(chǎn)品”，選擇一種具體的數(shù)據(jù)庫相當(dāng)于由多個產(chǎn)品中的一個來配置，這點(diǎn)與抽象工廠模式的意圖是相吻合的。因此，抽象工廠模式滿足我們設(shè)計的要求，結(jié)構(gòu)圖見圖2。

圖2 抽象工廠模式在系統(tǒng)中的應(yīng)用

抽象工廠模式的最大好處是易于交換產(chǎn)品系列，由于具體工廠類在一個應(yīng)用中只需要在初始化的時候出現(xiàn)一次，這就使得改變一個應(yīng)用的具體工廠變得非常容易，它只需要改變具體工廠即可使用不同的產(chǎn)品配置。本處中如果將訪問Access數(shù)據(jù)庫更改為訪問Sql Server，我們只要將具體工廠AccessFactory更改為Sqlserverfactory就行了。抽象工廠模式的另一好處是，它讓具體的創(chuàng)建實例過程與客戶端分離，客戶端是通過它們的抽象接口操縱實例，產(chǎn)品的具體類名也被具體工廠的實現(xiàn)分離，不會出現(xiàn)在客戶代碼中。本處客戶端認(rèn)識的只有IUser和IDepartment，至于它是用Sql Server來實現(xiàn)還是Access來實現(xiàn)就不知道了。這也正好符合面向?qū)ο蟮拈_放-封閉原則。

2.外觀模式應(yīng)用

2.1 外觀模式概述

外觀模式的意圖是為子系統(tǒng)中的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。

2.2 模式的使用

外觀模式在實際開發(fā)中較多的運(yùn)用于N層架構(gòu)的應(yīng)用程序。在設(shè)計初期階段，基于MVC模式架構(gòu)本系統(tǒng)，分成三個層次：系統(tǒng)層（數(shù)據(jù)訪問層）、核心層（業(yè)務(wù)層）、應(yīng)用層。這樣在數(shù)據(jù)訪問層和業(yè)務(wù)邏輯層、業(yè)務(wù)邏輯層和表示層的層與層之間建立Facade，為復(fù)雜的子系統(tǒng)提供一個簡單拼接口，降低了客戶程序與內(nèi)部子系統(tǒng)間的耦合。

圖3 系統(tǒng)架構(gòu)圖

在圖3這個架構(gòu)中，這里顯示了本系統(tǒng)中主要的邏輯層。分別為：用戶層UI，業(yè)務(wù)外觀層Business Facade，業(yè)務(wù)規(guī)則層Business Rule，數(shù)據(jù)訪問層Data Access，另外還有業(yè)務(wù)實體層作為各層之間的數(shù)據(jù)傳輸。

在本社區(qū)衛(wèi)生服務(wù)系統(tǒng)中，有部分操作只是簡單的從數(shù)據(jù)庫根據(jù)條件提取數(shù)據(jù)，不需要經(jīng)過任何處理，而直接將數(shù)據(jù)顯示到網(wǎng)頁上，比如用戶瀏覽門戶網(wǎng)站上新聞、公告等。而另外一些操作，比用戶通過門戶網(wǎng)站登陸、家庭病床申請、日志的記錄、操作還原等等，這部分往往有許多不同的功能的類，操作起來也比較復(fù)雜。如果采用傳統(tǒng)的三層結(jié)構(gòu)，這些業(yè)務(wù)邏輯一般是會放在中間層，那么對內(nèi)部的這些種類繁多，使用方法也不同的類的調(diào)用任務(wù)，就完全落到了表示層。這樣勢必會增加表示層的代碼量，將表示層的任務(wù)復(fù)雜化，和表示層只負(fù)責(zé)接受用戶的輸入并返回結(jié)果的任務(wù)不太相稱，并增加了層與層之間的耦合程度。

于是就引入了一個外觀Facade層，讓這個Facade來負(fù)責(zé)社區(qū)衛(wèi)生系統(tǒng)內(nèi)部類的調(diào)用，并為表示層提供了一個單一而簡單的接口，圖4所示為外觀模式在社區(qū)衛(wèi)生服務(wù)系統(tǒng)中的應(yīng)用。

圖4 外觀模式在社區(qū)衛(wèi)生服務(wù)系統(tǒng)中的應(yīng)用

從圖4中可以看到，UI層將請求發(fā)送給業(yè)務(wù)外觀層，業(yè)務(wù)外觀層對請求進(jìn)行初步的處理，判斷是否需要調(diào)用業(yè)務(wù)規(guī)則層，還是直接調(diào)用數(shù)據(jù)訪問層獲取數(shù)據(jù)。最后由數(shù)據(jù)訪問層訪問數(shù)據(jù)庫并按照來時的步驟返回結(jié)果到UI層。

社區(qū)衛(wèi)生服務(wù)系統(tǒng)開發(fā)過程中，把業(yè)務(wù)邏輯層分成了業(yè)務(wù)外觀層和業(yè)務(wù)規(guī)則層。外觀層將一些復(fù)雜的類封裝成一個接口，這樣表示層和業(yè)務(wù)層的調(diào)用就通過業(yè)務(wù)外觀層來解耦，既減輕了表示層的壓力，同時又使得層之間的藕合度降低，每個層各司其職。系統(tǒng)結(jié)構(gòu)如圖4所示，系統(tǒng)中的具體業(yè)務(wù)都是放在業(yè)務(wù)規(guī)則層，同時也定義好業(yè)務(wù)外觀層，業(yè)務(wù)外觀層是業(yè)務(wù)規(guī)則的實現(xiàn)接口，表示層WebUI通過外觀層里的接口調(diào)用規(guī)則層里的具體業(yè)務(wù)。

使用外觀模式的最大好處降低了子系統(tǒng)與客戶之間的耦合關(guān)系。在開發(fā)階段，子系統(tǒng)往往因為不斷的重構(gòu)深化而變得越來越復(fù)雜，大多數(shù)的模式使用時也都會產(chǎn)生很多很小的類，給外部調(diào)用它們的用戶程序帶來了使用上的困難，增加外觀可以提供一個簡單的接口，減少它們之間的依賴。另一好處是在維護(hù)一個遺留的大型系統(tǒng)時，可能這個系統(tǒng)已經(jīng)非常難以維護(hù)和擴(kuò)展了，但由于它包含非常重要的功能，新的需要開發(fā)必須要依賴于它。此時為新系統(tǒng)開發(fā)一個外觀Facade類，來提供設(shè)計粗糙或高度復(fù)雜的遺留代碼的比較清晰簡單的接口，讓新系統(tǒng)與Fa?ade對象交互，F(xiàn)a?ade與遺留代碼交互所有復(fù)雜的工作。

從上文及上文圖示可以總結(jié)出通過應(yīng)用設(shè)計模式對系統(tǒng)的設(shè)計進(jìn)行改進(jìn)后給系統(tǒng)帶來的好處有：

（1）設(shè)計，重用設(shè)計比重用代碼更有意義，自動帶來代碼重用；

（2）應(yīng)用設(shè)計模式可以讓重構(gòu)系統(tǒng)變得容易，可確保開發(fā)正確的代碼，并降低在設(shè)計或?qū)崿F(xiàn)中出現(xiàn)錯誤的可能性。還可以為重寫其他應(yīng)用程序提供很好的系統(tǒng)架構(gòu)；

（3）設(shè)計模式是可復(fù)用的：設(shè)計模式提供了一個現(xiàn)成的解決方案，可根據(jù)需要適應(yīng)不同的問題，可幫助設(shè)計者更快更好地完成系統(tǒng)設(shè)計：同時，設(shè)計模式幫助系統(tǒng)設(shè)計者做出有利于系統(tǒng)復(fù)用的選擇，避免設(shè)計損害了系統(tǒng)的復(fù)用性；

在面向?qū)ο蟮木幊讨校浖幊倘藛T更加注重以往代碼的重用性和可維護(hù)性。通過提供一個類和對象之間的作用關(guān)系以及它們之間潛在聯(lián)系的說明規(guī)范，設(shè)計模式甚至能夠提高己有系統(tǒng)的文檔管理和系統(tǒng)維護(hù)的有效性。需要指出的是，設(shè)計模式并不保證成功。一個設(shè)計模式的描述表明該模式什么時候是可適用的，但是只有經(jīng)驗的積累才能更好地確保何時一個特定的設(shè)計模式能夠改良一個設(shè)計。

參考文獻(xiàn)：

[1]任婧.設(shè)計模式在虛擬交易平臺中的應(yīng)用與研究[D].[碩士學(xué)位論文].山西：太原理工大學(xué)，2008.

[2]龍狼.MVC設(shè)計模式帶來更好的軟件結(jié)構(gòu)和代碼重用[EB/OL].http：//www.soidc.net/articles/1213781103032/20050406/1214037288933_1.html.2005-04-06.

[3]丁育萍.NET環(huán)境下設(shè)計模式的選擇與應(yīng)用[D].[碩士學(xué)位論文].江蘇：江南大學(xué)，2010.

[4]Gamma E，Helm T，Johnson R，and Vlissides[J].Design Patterns：Abstraction and Reuse of Object-Oriented Design.Proceedings of ECOOP’93：405-431.

[5]薛冰，曹作良.設(shè)計模式和數(shù)據(jù)持久層框架在Web系統(tǒng)中的應(yīng)用[J].天津理工學(xué)院學(xué)報，2004.20（1）：72-74.