【正文】 持 久 層 的 持 久 對 象 ， 只 有 屬 性 ， 沒 有 行 為 圖 數(shù)據(jù)訪問層的模塊結(jié)構(gòu)圖 層。 在 Petshop 中，系統(tǒng)需要處理的數(shù)據(jù)庫對象分為兩類：一是數(shù)據(jù)實 體，對應(yīng)數(shù)據(jù)庫中相應(yīng)的數(shù)據(jù)表。它們沒有行為，僅用于表現(xiàn)對象的數(shù)據(jù)。這些實體類都被放到 Model 程序集中，這些對象并不具有持久化的功能，簡單地說，它們是作為數(shù)據(jù)的載體，便于業(yè)務(wù)邏輯針對相應(yīng)數(shù)據(jù)表進行讀 /寫操作。雖然這些類的屬性分別映射了數(shù)據(jù)表的列，而每一個對象實例也恰恰對應(yīng)于數(shù)據(jù)表的每一行，但這些實體類卻并不具備對應(yīng)的數(shù)據(jù)庫訪問能力，由于數(shù)據(jù)訪問層和業(yè)務(wù)邏輯層都將對這些數(shù)據(jù)實體進行操作，因此程序集 Model 會被這兩層的模塊所引用。 層。 第二類數(shù)據(jù)庫對象則是數(shù)據(jù)的業(yè)務(wù)邏輯對象。這里所指的業(yè)務(wù)邏輯，并 非業(yè)務(wù)邏輯層意義上的領(lǐng)域（ domain）業(yè)務(wù)邏輯（從這個意義上，更 應(yīng)當將業(yè)務(wù)邏輯層稱為 “ 領(lǐng)域邏輯層 ” ），一般意義上說，這些業(yè)務(wù)邏輯即為基本的數(shù)據(jù)庫操作，包括 Select， Insert， Update 和 Delete。由于這些業(yè)務(wù)邏輯對象，僅具有行為而與數(shù)據(jù)無關(guān)，因此它們均被抽象為一個單獨的接口模塊 IDAL。 首先，它體現(xiàn)了 “ 職責(zé)分離 ” 的原則。將數(shù)據(jù)實體與其行為分開，使得兩者之間依賴減弱，當數(shù)據(jù)行為發(fā)生改變時，并不影響 Model 模塊中的數(shù)據(jù)實體對象，避免了因一個類職責(zé)過多、過大，從而導(dǎo)致該類的引用者發(fā)生 “ 災(zāi)難性 ” 的 影響。其次，它體現(xiàn)了 “ 抽象 ” 的精神，或者說是 “ 面向接口編程 ” 的最佳體現(xiàn)。抽象的接口模塊 IDAL，與具體的數(shù)據(jù)庫訪問實現(xiàn)完全隔離。這種與實現(xiàn)無關(guān)的設(shè)計，保證了系統(tǒng)的可擴展性，同時也保證了數(shù)據(jù)庫的可移植性。 第三章 系統(tǒng)架構(gòu)設(shè)計 19 層。 DALFactory 模塊專門管理 DAL 對象的創(chuàng)建，便于業(yè)務(wù)邏輯層訪問。 對于數(shù)據(jù)訪問層來說，最 復(fù)雜 的是 SQL 語句的處理。在早期的 CS 結(jié)構(gòu)中，由于未采用三層式架構(gòu)設(shè)計，數(shù)據(jù)訪問層和業(yè)務(wù)邏輯層是緊密糅合在一起的，因此， SQL 語句遍布與系統(tǒng)的每一個角落。這給程序的維護帶來極大的困難。此外 ，由于 Oracle 使用的是 PLSQL，而 SQL Server 和 Sybase 等使用的是 TSQL，兩者雖然都遵循了標準 SQL 的語法，但在很多細節(jié)上仍有區(qū)別，如果將 SQL 語句大量的使用到程序中，無疑為可能的數(shù)據(jù)庫移植也帶來了困難。 解決的辦法是 “ 依賴注入 ” 。 “ 依賴注入 ” 的功能通常是用專門的 IoC 容器提供的，在 Java 平臺下，這樣的容器包括 Spring， PicoContainer 等。而在 .Net 平臺下，最常見的則是。不過，在 Petshop 系統(tǒng)中，并不需要專門的容器來實現(xiàn) “ 依賴注入 ” ，簡單的做法 還是利用配置文件和反射功能來實現(xiàn)。也就是說，我們可以在 文件中，配置好具體的 Factory 對象的完整的類名。然而，當我們利用配置文件和反射功能時， 并不需要 具體工廠的創(chuàng)建，我們完全可以在配置文件中，直接指向具體的數(shù)據(jù)庫對象實現(xiàn)類，例如 。那么，抽象工廠模式中的相關(guān)工廠就可以簡化為一個工廠類了，所以我將這種模式稱之為 “ 具有簡單工廠特質(zhì)的抽象工廠模式 ” 。 層。 SQLServerDAL 和 OracleDAL 模塊均實現(xiàn) IDAL 模塊的接口，其中包含的邏輯就是對數(shù)據(jù)庫的 Select， Insert， Update 和 Delete 操作。因為數(shù)據(jù)庫類型的不同，對數(shù)據(jù)庫的操作也有所不同，代碼也會因 此有所區(qū)別 [14]。 此外，抽象出來的 IDAL 模塊，除了解除了向下的依賴之外，對于其上的業(yè)務(wù)邏輯層，同樣僅存在弱依賴關(guān)系，如下圖所示： B L LI D A LD A L F a c t o r y M o d e l業(yè) 務(wù) 邏 輯 層 ， 核 心 業(yè) 務(wù) 代 碼 都 在 其 中 。 圖 業(yè)務(wù)邏輯層的模塊結(jié)構(gòu)圖 20 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) 層。 BLL 層 是業(yè)務(wù)邏輯層的核心模塊，它包含了整個系統(tǒng)的核心業(yè)務(wù)。在業(yè)務(wù)邏輯層中，不能直接訪問數(shù)據(jù)庫，而必須通過 數(shù)據(jù)訪問層。注意圖中對數(shù)據(jù)訪問業(yè)務(wù)的調(diào)用，是通過接口模塊 IDAL 來完成的。既然與具體的數(shù)據(jù)訪問邏輯無關(guān)， 那么 層與層之間的關(guān)系就是松散耦合的。如果此時需要修改數(shù)據(jù)訪問層的具體實現(xiàn)，只要不涉及到 IDAL 的接口定義，那么業(yè)務(wù)邏輯層就不會受到任何影響。畢竟，具體實現(xiàn)的 SQLServerDAL 和 OracalDAL 與業(yè)務(wù)邏輯層沒有 任何 關(guān)系。 Petshop 中的設(shè)計模式 設(shè)計模式從本質(zhì)上說是一種規(guī)則，從形式上說，分為創(chuàng)建型、結(jié)構(gòu)型、行為型。 設(shè)計模式的應(yīng)用是為了實現(xiàn)軟件設(shè)計中的幾個原則，其中一個重要原則是：減 少模塊之間的耦合程度。為了確保這個目的，在設(shè)計一個類時，要針對接口，而非實現(xiàn)（ Programming to an Interface， not an Implementation） 。 設(shè)計的時候只關(guān)心類的接口，編程的時候可以先實現(xiàn)一個簡單的接口，供別的模塊調(diào)用。使用一個類的時候只對接口工作，不關(guān)心具體的實現(xiàn)，也不關(guān)心具體的類型。 工廠模式 ， 應(yīng)用于 “ 一系列相互依賴的對象 ” 的創(chuàng)建工作，以適應(yīng)需求的變化 ： DALFactory：數(shù)據(jù)訪問層的抽象工廠（ 通過依賴注入 決定創(chuàng)建哪種數(shù)據(jù)庫類型的數(shù)據(jù)訪問層?？梢赃x擇 SQLServer 或者 Oracle 數(shù)據(jù)庫。 依賴注入是指將應(yīng)用程序的組件在運行時注入給應(yīng)用中。在 中使用依賴注入 技術(shù)，可以有效地 降低 模塊間依賴關(guān)系 ， 并在運行時為應(yīng)用程序動態(tài)注入依賴的具體內(nèi)容，以提升組件重用性 ,并為應(yīng)用程序搭建一個具有較強靈活性和擴展性的 平臺 [15]）。 CacheDependencyFactory：緩存依賴類的工廠類。（創(chuàng)建具體表的緩存依賴） 。 MessagingFactory：異時處理消息隊列的抽象工廠（反射創(chuàng)建具體的異時處理類） 。 ProfileDALFactory： ProfileDAL 的工廠類 (反射選擇創(chuàng)建 Oracle 和 SQL Server的 ProfileDAL)。 ： IorderStrategy。 ： CategoryDataProxy， ItemDataProxy， ProductDataProxy。 第三章 系統(tǒng)架構(gòu)設(shè)計 21 本 系統(tǒng) 架構(gòu)設(shè)計 策略 本系統(tǒng) 是 在 Petshop 項目架構(gòu)設(shè)計的基礎(chǔ)上，立足于本系統(tǒng)項目的實際情況和特點，在其基礎(chǔ)上進行部分精簡和修改 得到的 ，比如減少了緩存依賴和策略模式的應(yīng)用等等 。 下圖是本系統(tǒng) 的 概覽 （ 其中 網(wǎng)站 架構(gòu)是核心部分） ： 圖 系統(tǒng)開發(fā) 總體 架 構(gòu) 項目結(jié)構(gòu)與簡介 圖 項目核心業(yè)務(wù)架構(gòu) 22 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) 表 本系統(tǒng) 項目列表及簡述 表 序號 項目名稱 描述 1 Web 表示層 2 Model 業(yè)務(wù)實體層 3 BLL 業(yè)務(wù)邏輯層 4 DALFactory 數(shù)據(jù)層的抽象工廠 (用于創(chuàng)建反射 ) 5 IDAL 數(shù)據(jù)訪問層的接口定義 6 SQLServerDAL SQLServer 數(shù)據(jù)訪問層 7 DBUtility 數(shù)據(jù)庫訪問組件基礎(chǔ)類 各層的 實現(xiàn)步驟為： ModelIDALSQLServerDALDALFactoryBLLWEB。 項目依賴關(guān)系 Web 引用 BLL。 BLL 引用 IDAL， Model， 使用 DALFactory 創(chuàng)建實例。 IDAL 引用 Model。 Model 無引用。 DALFactory 引用 IDAL，通過讀取 里設(shè)置的程序集，加載類的實例，返回給 BLL 使用。 SQLServerDAL 引用 Model 和 IDAL，被 DALFactory 加載的程序集，實現(xiàn)接口里的方法。 實現(xiàn)步驟 創(chuàng)建 Model，實現(xiàn)業(yè)務(wù)實體。 創(chuàng)建 IDAL，實現(xiàn)接口。 創(chuàng)建 SQLServerDAL，實現(xiàn)接口里的方法。 增加 里的配置信息，為 SQLServerDAL 的程序集。 創(chuàng)建 DALFactory，返回程序集的指定類的實例。 創(chuàng)建 BLL，調(diào)用 DALFactory，得到程序集指定類的實例，完成數(shù)據(jù)操作方法。 創(chuàng)建 WEB，調(diào)用 BLL 里的數(shù)據(jù)操作方法。 第四章 系統(tǒng)分析與設(shè)計 23 第四章 系統(tǒng) 分析與設(shè)計 建模技術(shù)與工具 UML 簡介 UML(Unified Modeling Language，統(tǒng)一建模語言 )是一種用于提取 OOAD 過程的產(chǎn)物和繪制軟件藍圖的標準圖 形化語言 ， 可以用 UML 對軟件密集型系統(tǒng)的制品進行可視化、詳述、構(gòu)造 和文檔化 [16]。它 為交流面向?qū)ο蟮脑O(shè)計中的需求、行為、體系結(jié)構(gòu)和實現(xiàn)提供了一套綜合的表示法并提供了一種創(chuàng)建和記錄系統(tǒng)模型的方法。 UML 是為了交流。 UML 由 9 個不同類型的圖組成，每種圖都著重于使用不同的方法來分析并定義系統(tǒng)。本文主 要 用到的 6 種 圖的簡要概括如下： 用例圖顯示了系統(tǒng)的外部可視行為， 描述了系統(tǒng)外的人員和系統(tǒng)的動作，以及系統(tǒng)的響應(yīng) 。 活動圖顯示了系統(tǒng)行為的詳細描述 ， 描述了單個功能需求內(nèi)部的細節(jié)行為，包括基本的場景和一些可選的場景。該 圖可用于確保徹底理解給定的功能。 組件圖顯示了系統(tǒng)的體系結(jié)構(gòu)， 描述了系統(tǒng)的可部署單元 (可執(zhí)行文件、組件、數(shù)據(jù)存儲和其他一些內(nèi)容 )以及一些接口，可部署單元通過這些接口進行交互。該圖可用于研究系統(tǒng)的體系結(jié)構(gòu)。 順序圖顯示了對象隨著時間的交互， 描述了某個功能需求的路徑或場景內(nèi)相對時間的詳細行為。該圖可用于理解系統(tǒng)元素之間的消息流程。 類圖顯示了類定義和關(guān)系， 描述了系統(tǒng)設(shè)計中的類和接口，以及它們之間的關(guān)系。該圖可用于定義內(nèi)部的、面向?qū)ο蟮拇a結(jié)構(gòu)。 包圖顯示了設(shè)計的層次結(jié)構(gòu)， 描述了設(shè)計的相關(guān)元素如何按組結(jié)合在一起，以及這些組如何相互依賴。該圖可用于將復(fù)雜的設(shè)計劃分為多個更易于管理的較小設(shè)計。 這些圖對于組織許多不同類型的元素將非常有用。 在 OOAD（面向?qū)ο蠓治雠c設(shè)計）中使用 UML 的核心目標是通過系統(tǒng)模型來學(xué)習(xí)并理解該 系統(tǒng) [18]。 24 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) 基于 UML 與 精簡 RUP 的面向?qū)ο蠼：喗? 傳統(tǒng)的軟件開發(fā)是從算法的角度進行建模。按照這種方法，所有的軟件都用過程或函數(shù)作為其主要構(gòu)造塊。這種觀點導(dǎo)致開發(fā)人員把精力集中于控制流程和對大的算法進行分解。這種觀點除了傾向于產(chǎn)生脆弱的系統(tǒng)之外沒有其他本質(zhì)上的害處。當需求發(fā)生變化（總會變 化的）以及系統(tǒng)增長（總會增長的）時，用這種方法建造的系統(tǒng)就會變得很難維護。 現(xiàn)代的軟件開發(fā)采用面向?qū)ο蟮挠^點進行建模。按照這種方法，所有軟件系統(tǒng)都用對象或類作為其主要構(gòu)造塊。簡單地講，對象通常是從問題空間或解空間的詞匯中抽取出來的東西；類是對具有共同性質(zhì)的一組對象（從建模者的視角）的描述。每一個對象都有標識（能夠?qū)λ?，以區(qū)別于其他對象）、狀態(tài)（通常有一些數(shù)據(jù)與它相聯(lián)系）和行為（能對該對象做某些事，它也能為其他對象做某些事）。 軟件過程是指實施于軟件開發(fā)和維護中的階段、方法、技術(shù)、實踐及相關(guān)產(chǎn)物的集合。行 之有效的軟件過程可以提高開發(fā)軟件組織的生產(chǎn)效率、提高軟件質(zhì)量、降低成本并減少風(fēng)險。目前市場上領(lǐng)先的軟件過程主要有 RUP、 OPENProcess和 OOSP。 對高質(zhì)量軟件的追求是過程發(fā)展的原動力。從宏觀看 ， 過程的標準化是質(zhì)量保證的手段之一 ； 從微觀看 ， 過程還可擁有具體的手段來改善和保證軟件質(zhì)量 [17]。 UML 在很大程度上是獨立于過程的，這意味著它不依賴于任何特殊的軟件開發(fā)生命周期。然而，為了從 UML 中得到最大的收益，應(yīng)該考慮這樣的過程，它是：用況驅(qū)動的、以體系結(jié)構(gòu)為中心的、迭代的和增量。而我們這里采用的就是 RUP。 RUP(Rational Unified Process， 統(tǒng)一軟件開發(fā)過程 )[19]是一 種基于構(gòu)件的迭代式開發(fā)方法 ， 該統(tǒng)一過程的出現(xiàn)恰恰滿足了現(xiàn)代軟件生產(chǎn)的需要 。它 是一種特別適應(yīng)于 UML的生命周期方法，是有效使用 UML的指南，與早期的瀑布式開發(fā)模型相比，它具有迭代式的增量開發(fā)、使用實例驅(qū)動、以軟件體系結(jié)構(gòu)為核心 3個鮮明特點，這使得 RUP非常適宜于開發(fā)復(fù)雜、技術(shù)難度大、需求多變、高風(fēng)險的項目。RUP歸納和整理了很多在實踐中總結(jié)出來的軟件工程的最佳實踐，是一個采用了面向?qū)ο笏枷?，并且結(jié)合了項目管理、質(zhì)量保 證等許多軟件工程知識綜合而成的一個非常完整和龐大的軟件方法。 第四章 系統(tǒng)分析與設(shè)計 25 RUP 可以用二維坐標來描述。橫軸通過時間組織，是過程展開的生命周期特征，體現(xiàn)開發(fā)過程的