南京理工大學-設(shè)計模式在分層架構(gòu)中的應(yīng)用分析-作業(yè)模板

1、軟件結(jié)構(gòu)設(shè)計與模式分析論文 論文題目：設(shè)計模式在企業(yè)管理分層架構(gòu)中的應(yīng)用 學 號： XX 姓 名： XX 聯(lián)系方式： XX 設(shè)計模式在企業(yè)管理分層架構(gòu)中的應(yīng)用摘要：設(shè)計模式（Design pattern）是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計經(jīng)驗的總結(jié)。使用設(shè)計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設(shè)計模式于己于他人于系統(tǒng)都是多贏的；設(shè)計模式使代碼編制真正工程化；設(shè)計模式是軟件工程的基石脈絡(luò)，如同大廈的結(jié)構(gòu)一樣。設(shè)計模式是一種抽象思想，它在對象的創(chuàng)建、組成以及行為等方面提供了一套精練的解決方案。分層架構(gòu)將某一應(yīng)用系統(tǒng)劃分成多個子任務(wù)組，每個

2、子任務(wù)組處于一個特定的抽象層次中。分析了傳統(tǒng)分層架構(gòu)存在的缺陷后，提出了將設(shè)計模式應(yīng)用到分層架構(gòu)中，解決了層與層之間以及各層內(nèi)部對象之間的高耦合問題，從而使架構(gòu)更加靈活，方便了系統(tǒng)的擴充和維護。1.引言 層既是一種軟件體系結(jié)構(gòu)風格，也是一種軟件體系結(jié)構(gòu)模式，它有助于將應(yīng)用系統(tǒng)分成子任務(wù)組，其中每個子任務(wù)組處于一個特定的抽象層次中。但是簡單的層次劃分并沒有解決對象之間的高耦合問題。將設(shè)計模式引入到分層架構(gòu)中能夠使得各層的內(nèi)部組成之間以及層與層之間的耦合度大大降低，擴展性大大提高，這樣既有利于將復(fù)雜問題分而治之，也有利于每一層更加靈活的進行重用。分層體系架構(gòu)使整個系統(tǒng)各部件分離，解除了“一變?nèi)珓印?/p>

3、的困擾。2.系統(tǒng)架構(gòu)與設(shè)計模式 如果說設(shè)計模式是微觀方面的內(nèi)容，那么架構(gòu)就可以說是宏觀方面的內(nèi)容。架構(gòu)描述了軟件體系基本的結(jié)構(gòu)化組織方案，提供了一套預(yù)先定義好的子系統(tǒng)來定制它們的職責，包括用于它們之間的規(guī)則和指南。架構(gòu)的物理實現(xiàn)往往表現(xiàn)為一套詳細而準確的類以及相關(guān)的配置文件，類與類之間功能各異，彼此調(diào)用，相互協(xié)作形成了對某一類重現(xiàn)問題的可重用、可擴展的解決方案。通常情況下架構(gòu)是要針對特定平臺的，例如 MVC 在 SmallTalk 中的實現(xiàn)是一個架構(gòu)，EJB是J2EE 下的一個架構(gòu)，254JavaBean 也是 Java 平臺下的架構(gòu)。 在實際基于某種架構(gòu)的應(yīng)用中通常所做的工作是擴展該架構(gòu)中的

4、子類以及組織架構(gòu)中類的實例。經(jīng)過大量的面向?qū)ο蟮钠髽I(yè)系統(tǒng)開發(fā)之后，就會發(fā)現(xiàn)不同的系統(tǒng)中會有大量相似結(jié)構(gòu)的出現(xiàn)。通常情況下這種相似結(jié)構(gòu)的解決方案也是相似的，而描述這種確定領(lǐng)域的相似需求和相似解決方案的工具便是設(shè)計模式。設(shè)計模式是系統(tǒng)設(shè)計師軟件開發(fā)經(jīng)驗的總結(jié)，設(shè)計模式相對于架構(gòu)更加抽象，架構(gòu)在不同的平臺下可能呈現(xiàn)出不同的表現(xiàn)形式，有時貌似不同的架構(gòu)可能完全出于同一種設(shè)計模式。一個架構(gòu)可以看作是由多個設(shè)計模式組合成的解決方案的物理實現(xiàn)，設(shè)計模式指導如何實現(xiàn)這個方案。3.設(shè)計模式對分層架構(gòu)的優(yōu)化設(shè)計典型的企業(yè)分層系統(tǒng)架構(gòu)是將系統(tǒng)分為三層，即表示層、業(yè)務(wù)層、數(shù)據(jù)層。每層完成不同的工作，但它們之間又不是相

5、互獨立的，而需要彼此通信，相互協(xié)作完成整個架構(gòu)的功能。數(shù)據(jù)層向業(yè)務(wù)層提供底層數(shù)據(jù)的訪問處理功能；業(yè)務(wù)層向表示層提供業(yè)務(wù)流程控制和數(shù)據(jù)模型封裝功能，避免了表示層直接訪問數(shù)據(jù)層，使得表示與數(shù)據(jù)處理的完全分離。傳統(tǒng)的三層結(jié)構(gòu)的框架圖如圖 1 所示：圖1 典型的三層結(jié)構(gòu)圖 表示層是不能直接與數(shù)據(jù)層進行通信的，而只能通過業(yè)務(wù)層與數(shù)據(jù)層進行通信，在傳統(tǒng)的三層架構(gòu)中已經(jīng)做到了這一點。但是，從圖 1 不難看出傳統(tǒng)三層架構(gòu)存在的缺陷，在實際的企業(yè)系統(tǒng)中一項業(yè)務(wù)可能會涉及到多個數(shù)據(jù)操作，業(yè)務(wù)層與數(shù)據(jù)層的耦合度比較高，這勢必要求負責業(yè)務(wù)層的每個開發(fā)人員對數(shù)據(jù)層的所有接口必須非常熟悉，才能完成各種數(shù)據(jù)操作。這不僅對業(yè)

6、務(wù)層的開發(fā)人員提出了高要求，而且在每個業(yè)務(wù)類中會充斥著大量的數(shù)據(jù)層的類。這樣一來數(shù)據(jù)層中某個部分發(fā)生變動可能會牽扯到多個業(yè)務(wù)層類的改動。為解決這一問題我們引入 Command 模式，在業(yè)務(wù)層與數(shù)據(jù)層之間加入命令對象層，如圖 2 所示。圖2 加入命令對象層之后的模式框架 引入 Command 模式后，雖然實現(xiàn)了業(yè)務(wù)層與數(shù)據(jù)層之間的脫耦，但是架構(gòu)中仍存在缺陷。每個表示層對象都對應(yīng)著一個業(yè)務(wù)層對象，因此在系統(tǒng)中可能就存在大量的業(yè)務(wù)類，而這些業(yè)務(wù)類中可能有許多功能相似的部分，使得這些相似的功能普遍存在于大量的業(yè)務(wù)類中。如此設(shè)計的缺陷也就暴露出來，相似功能分別由不同人員重復(fù)開發(fā)，一是造成了資源的浪費，更

7、主要的是給系統(tǒng)的維護和擴充帶來極大的不便，如果某一業(yè)務(wù)功能需要擴充或者變動，那么與此相關(guān)的所有業(yè)務(wù)類都要進行改變。為了使表示層與業(yè)務(wù)層之間的聯(lián)系變得松散，我們引入 Façade（門面）模式，在這兩層之間加入一個門面對象層，如圖 3 所示。圖3 加入門對象層之后的模式框架如此一來便對表示層與業(yè)務(wù)層進行了脫耦，當某個業(yè)務(wù)發(fā)生變化時，要么改變門面中的業(yè)務(wù)對象的組合要么對業(yè)務(wù)層中的業(yè)務(wù)類進行修改，而不需要對調(diào)用該業(yè)務(wù)對象的所有表示層對象進行修改。這也使得系統(tǒng)更容易擴充，當有新業(yè)務(wù)添加時，我們只要把新的業(yè)務(wù)注冊到門面對象中，表示層就可以對其進行透明訪問。4.設(shè)計模式在分層架構(gòu)中的實現(xiàn)上節(jié)中給出

8、了利用 Command 模式和 Façade 模式對分層體系架構(gòu)的優(yōu)化方案，在這節(jié)中將以設(shè)備管理系統(tǒng)為背景詳細闡述優(yōu)化之后的系統(tǒng)架構(gòu)的實現(xiàn)。設(shè)備管理系統(tǒng)包括設(shè)備的基礎(chǔ)信息管理、設(shè)備的申請管理、申請的審批管理等等業(yè)務(wù)，其中設(shè)備的申請包括了設(shè)備的購置申請、調(diào)撥申請、報廢申請。圖 4 所示的是申請管理的類圖。圖 4 設(shè)備申請管理的類圖Command 模式涉及到三個角色，即命令發(fā)出者角色、命令角色和命令接收者角色。業(yè)務(wù)層對象充當命令發(fā)出者角色，命令對象充當命令角色，數(shù)據(jù)層對象充當命令接受者角色。在每個命令對象中都持有命令接收者的引用，命令對象通過調(diào)用命令接收者中的具體方法來完成相應(yīng)的命令。例

9、如，新增一條設(shè)備購置申請信息包括合法性驗證、添加記錄、登記日志三個操作，我們將這三個具體的操作組合成一個命令對象。因此命令對象PurchaseCommand 的命令接收者是 PurchaseDao、LogDao 和 ValidateDao。它向業(yè)務(wù)層提供的新增購置申請的命令執(zhí)行接口是 addApply，在接口中會執(zhí)行命令接收者的具體指令。示例 1 給出了設(shè)備購置申請管理的業(yè)務(wù)類PurchaseApply 和命令類 PurchaseCommand 的主要代碼框架。示例 1：public class PurchaseApplyPurchaseCommand command;public void

10、addApply()command.addApply();public class PurchaseCommand ValidateDao dao1;PurchaseDao dao2;LogDao dao3;public void addApply()dao1.validate();/執(zhí)行命令接收者 1 中的命令dao2.add();dao3.log();/執(zhí)行命令接收者 2 中的命令 為了向表示層提供統(tǒng)一的訪問業(yè)務(wù)層的接口，上面的設(shè)計方案中在表示層與業(yè)務(wù)層之間加入了一個門面層。表示層對象只要告訴門面所要完成的業(yè)務(wù)即可，而不必再關(guān)心操作具體是如何實現(xiàn)的。門面模式涉及到了三個角色，即訪問門面的客

11、戶角色、門面角色 、子系統(tǒng)角色。在上面設(shè)計方案中充當三個角色的分別是表示層對象、門面對象、業(yè)務(wù)層對象。門面對象持有所有業(yè)務(wù)對象的引用，它會根據(jù)表示層的不同請求將不同的業(yè)務(wù)對象進行組合來完成相應(yīng)的業(yè)務(wù)。示例 2 給出了門面對象的主要代碼框架。示例 2：public class Facadepublic void execute()switch(business)case “purchase”:if(operation.equals(“add”)PurchaseApply.addApply();if(operation.equals(“update”)break;case “exchange”:i

12、f(operation.equals(“add”)ExchangeApply.addApply();if(operation.equals(“update”)break;case “reject”:從門面對象的代碼可以看出，當有新的業(yè)務(wù)添加到系統(tǒng)時所做的工作就是，編寫新業(yè)務(wù)類并在門面對象中進行登記，然后再與相應(yīng)的其他業(yè)務(wù)進行組合調(diào)用就可以滿足需求，而沒有對已有的業(yè)務(wù)類進行大量修改。這樣就很輕松的實現(xiàn)了系統(tǒng)的擴充。5.結(jié)論雖然分層會增加代碼程序的復(fù)雜性，但是使得整個系統(tǒng)的構(gòu)架更加清晰明了，更加易于理解。因為系統(tǒng)被嚴格地分層，如果某一天某個功能的業(yè)務(wù)邏輯發(fā)生變化，只要更新業(yè)務(wù)邏輯層就行，不需要驚動其他層，同樣道理，如果其他層發(fā)生了變化的話，也不會影響其他層，使得系統(tǒng)穩(wěn)定性增加。系統(tǒng)的分層使得各部分各負其責，避免了“一變?nèi)珓印?，也方便了開發(fā)人員的分工，發(fā)揮各自的長處。將設(shè)計模式貫穿于整個架構(gòu)中，能使架構(gòu)的各部分更好地通信、更有效地協(xié)調(diào)工作。同時設(shè)計模式在各層中的應(yīng)用使得整個架構(gòu)更容易擴充、更