【正文】 界面作為 HTML顯示于客戶端的瀏覽器中。 的執(zhí)行架構(gòu) 。當(dāng) ， CLR(Common Language Runtime)會將 MSIL代碼，并存放在服務(wù)器上。執(zhí)行的結(jié)果轉(zhuǎn)換成標(biāo)準(zhǔn)的 HTML， 再 發(fā)送給 瀏覽 器顯示。 窗 體 標(biāo) 題窗 體 標(biāo) 題瀏覽器發(fā)出請求 輸出緩存 瀏覽器 Web 服務(wù)器 由 JIT 編譯 生成 MSIL MSIL 裝配件緩存 進行二次編譯 分析器找到runat=”server” 標(biāo)記，解釋執(zhí)行源代碼 ASPX 文件中原有的 HTML 代碼 請求服務(wù)器程序 10 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) HTML元素，并充分支持事件驅(qū)動機制， 而 不必考慮如何將服務(wù)器端的信息回送瀏覽器。 （ CodeBehind）技術(shù) 通過使用 CodeBehind技術(shù)、用戶控件、自定義控件和組件等方法，可以很好地將程序的執(zhí)行代碼和邏輯代 碼分開，兩者互不影 響 ，從而實現(xiàn)了結(jié)構(gòu)化的 Web頁面設(shè)計。 其中 一些新的聲明性數(shù)據(jù)綁定性語法允許程序設(shè)計人員不僅可以綁定到數(shù)據(jù)源，而且可以綁定到簡單屬性、集合、表達式或從方法調(diào)用所返回的結(jié)果中。 （ Dataset）。 是一種編譯型的編程框架，它除了和 ASP 一樣可以采用 VBScript和 Jscript 作為編程語言外，還可以用 VB 和 C來編 寫 ， 這就決定了它功能的強大，可以進行很多 底 層操作而不必借助于其他編程語言。 第二章 平臺、技術(shù)與工具概述 11 的運行及開發(fā)環(huán)境 運行 應(yīng)用程序，首先要建立和配置運行環(huán)境，這包括服務(wù)器端運行環(huán)境與客戶端運行環(huán)境。具有使用方便 、 可伸縮性好 以及 與相關(guān)軟件集成程度高等優(yōu)點 。性能、可伸縮性及可靠性是基本要求，而進入市場時間也非常關(guān)鍵。從數(shù)據(jù)管理和分析角度看，將原始數(shù)據(jù)轉(zhuǎn)化為商業(yè)智能和充分利用 Web 帶來的機會非常重要。作為重要的基準(zhǔn)測試可伸縮性和速度獎的記錄保持者， SQL Server 2021 是一個具備完全 Web 支持的數(shù)據(jù)庫產(chǎn)品，提供了對可擴展標(biāo)記語言 (XML)的核心支持以及在 Inter 上和防火墻外進行查詢的能力。 12 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) 水晶報表概述 水晶報表是用于數(shù)據(jù)訪問 ， 具有強大的內(nèi)容創(chuàng)建、 集成功能和高效的 報表 與信息交互的通用體系結(jié)構(gòu)，允許用戶快速響應(yīng)任何報表和應(yīng)用程序開發(fā)需求。 Crystal Reports可以實現(xiàn)快速的將任何數(shù)據(jù)轉(zhuǎn)化為強大的、交互式的報表內(nèi)容；將報表集成、修改和查閱緊密集成到 .NET， Java和 COM應(yīng)用中；使最終用戶得以通過門戶、無線設(shè)備和 Microsoft office文檔對報表進行訪問和交互。 Crystal Reports提供程序開發(fā)人員可視化分析產(chǎn)生報表的功能，使得程序開發(fā)人員在不需要編寫代碼的情況下，只要使用 Crystal Reports Designer界面就能快速創(chuàng)建復(fù)雜和專業(yè)的交互式圖表和報表 。 架構(gòu)設(shè)計在建立 Web應(yīng)用程序中起著關(guān)鍵作用，會影響系統(tǒng)的可擴展性、可靠性、可重用性以及開發(fā)效率 [5]。隨著用戶需求的變化、技術(shù)的發(fā)展，我們身邊各式各樣的系統(tǒng)也日趨復(fù)雜。 架構(gòu)中包含了關(guān)于各元素應(yīng)如何彼此相關(guān)的信息。因此，架構(gòu)首先是對系統(tǒng)的抽象， 這種 抽象去除了不影響它 們?nèi)绾问褂?、其他元素如何使用以及如何與其他元素關(guān)聯(lián)或交互的細節(jié)。根據(jù)這種劃分，架構(gòu)屬于公有部分，而私有部分 ——即僅與內(nèi)部具體實現(xiàn)有關(guān)的細節(jié) ——是不屬于架構(gòu)的。其實，關(guān)注大局，把握整體，不僅僅是軟件系統(tǒng)架構(gòu)學(xué)科的主題，還是所有系統(tǒng)科學(xué)研究的對象 。 ” 分層架構(gòu)簡介 傳統(tǒng)的系統(tǒng)設(shè)計方法越來越不能滿足人們在封裝、復(fù)用、擴展、移置等方面的要求，多層架構(gòu)的思想應(yīng)運 而生 [7]。 所謂分層思想，就是這樣一種分工：它將系統(tǒng)按不同的職責(zé)組織成有序的層次。 三層結(jié)構(gòu)是基于模塊化程序設(shè)計的思想，為實現(xiàn)分解應(yīng)用程序的需求，而逐漸形成的一種標(biāo)準(zhǔn)模式的模塊劃分方法。區(qū)分層次的目的即為了 “ 高內(nèi)聚，低耦合 ” 的思想。完善的三層結(jié)構(gòu)的要求是 ： 修改表現(xiàn)層而不用修改邏輯層 ， 修改邏輯層而不用修改數(shù)據(jù)層。簡單的說法就是實現(xiàn)對數(shù)據(jù)表的 Select， Insert， Update， Delete 的操作。在 Petshop 的數(shù)據(jù)訪問層中，并沒有使用 ORM，從而導(dǎo)致了代碼量的增加，可以看作是整個設(shè)計實現(xiàn)中的一大敗筆。它是整個系統(tǒng)的核心，它與這個系統(tǒng)的業(yè)務(wù)（領(lǐng)域）有關(guān)。 業(yè)務(wù)邏輯層無疑是系統(tǒng)架構(gòu)中體現(xiàn)核心價值的部分。業(yè)務(wù)邏輯層的用途有很多，例如：驗證用戶輸入數(shù)據(jù)、緩存從數(shù)據(jù)庫中讀取的數(shù)據(jù) ? ? 但是，業(yè)務(wù)邏輯層的實際目的是將 “ 數(shù)據(jù)訪問層 ” 的最基礎(chǔ)的存儲 邏輯組合起來，形成一種業(yè)務(wù)規(guī)則。 表示層位于 最上層，通俗講就是展現(xiàn)給用戶的界面，即用戶在使用一個系統(tǒng)的時候 的所見所得 ，用于顯示和接收用戶提交的數(shù)據(jù)，為用戶提供交互式的界面。 在這一層中，理想的狀態(tài)是不 包括系統(tǒng)的業(yè)務(wù)邏輯 ， 表示層中的邏輯代碼僅與界面元素有關(guān)。 表 示 層 ：界 面 文 件 （ * . a s p x ）隱 藏 代 碼 文 件 （ * . a s p x . c s ）邏 輯 層 ：業(yè) 務(wù) 邏 輯 層 （ B L L ）數(shù) 據(jù) 訪 問 層 （ D A L ）數(shù) 據(jù) 層 ：存 儲 過 程 （ S P ）數(shù) 據(jù) 庫 （ S Q L 數(shù) 據(jù) 庫 ） 圖 基于 的三層架構(gòu)實現(xiàn) 模型 [9] 最后 再 來討論一下分層架構(gòu)的利弊分析， 首先是 優(yōu)點： ， 開發(fā)人員可以只關(guān)注整個結(jié)構(gòu)中的其中某一層 。 每一層只實現(xiàn)相對獨立的功能，所以各層都可以采用最為適合的技術(shù)來實現(xiàn) ， 而且便于測試和維護。 ， 可以很容易的用新的實 現(xiàn)來替換原有層次的實現(xiàn)。 工程的靈活性好，當(dāng)任何一層發(fā)生變化時，只要保持層間接口關(guān)系不變，則其它各層都不會受到影響。 概括來說，分層式設(shè)計可以達 到 如下目的：分散關(guān)注、松散耦合、邏輯復(fù)用、標(biāo)準(zhǔn)定義。這種修改尤其體現(xiàn)在自上而下的方向。 。 縱觀以上分析，分層架構(gòu)有利有弊。分層架構(gòu)可以降低層內(nèi)變化的成本，而對于 API 的變化非常敏感。 API 的變動對于分層架構(gòu)是致命的，修改起來難度非常大。 Petshop 項目的 系統(tǒng) 架構(gòu)設(shè)計 大家都知道，一直以來，在 .NET 和 Java 之間爭論不休，到底使用哪個平臺開發(fā)的企業(yè)級應(yīng)用性能最好、結(jié)構(gòu)最優(yōu)、生產(chǎn)力 最高 [10]。用戶做比較的這個項目就是 Petshop[11]。 正因為 Petshop 肩負著上面所說的重任，各方面必須是最優(yōu)的， 因此 架構(gòu)設(shè)計是 經(jīng)過慎重考慮的。 Petshop 雖然是一個小型的項目，系統(tǒng)架構(gòu)與代碼都比較簡單，卻也凸現(xiàn)了許多頗有價值的設(shè)計與開發(fā)理念。 在 Petshop 中，系統(tǒng)需要處理的數(shù)據(jù)庫對象分為兩類：一是數(shù)據(jù)實 體，對應(yīng)數(shù)據(jù)庫中相應(yīng)的數(shù)據(jù)表。這些實體類都被放到 Model 程序集中，這些對象并不具有持久化的功能，簡單地說，它們是作為數(shù)據(jù)的載體，便于業(yè)務(wù)邏輯針對相應(yīng)數(shù)據(jù)表進行讀 /寫操作。 層。這里所指的業(yè)務(wù)邏輯，并 非業(yè)務(wù)邏輯層意義上的領(lǐng)域（ domain）業(yè)務(wù)邏輯（從這個意義上，更 應(yīng)當(dāng)將業(yè)務(wù)邏輯層稱為 “ 領(lǐng)域邏輯層 ” ），一般意義上說，這些業(yè)務(wù)邏輯即為基本的數(shù)據(jù)庫操作，包括 Select， Insert， Update 和 Delete。 首先，它體現(xiàn)了 “ 職責(zé)分離 ” 的原則。其次，它體現(xiàn)了 “ 抽象 ” 的精神，或者說是 “ 面向接口編程 ” 的最佳體現(xiàn)。這種與實現(xiàn)無關(guān)的設(shè)計，保證了系統(tǒng)的可擴展性，同時也保證了數(shù)據(jù)庫的可移植性。 DALFactory 模塊專門管理 DAL 對象的創(chuàng)建，便于業(yè)務(wù)邏輯層訪問。在早期的 CS 結(jié)構(gòu)中，由于未采用三層式架構(gòu)設(shè)計，數(shù)據(jù)訪問層和業(yè)務(wù)邏輯層是緊密糅合在一起的，因此， SQL 語句遍布與系統(tǒng)的每一個角落。此外 ，由于 Oracle 使用的是 PLSQL，而 SQL Server 和 Sybase 等使用的是 TSQL，兩者雖然都遵循了標(biāo)準(zhǔn) SQL 的語法，但在很多細節(jié)上仍有區(qū)別，如果將 SQL 語句大量的使用到程序中，無疑為可能的數(shù)據(jù)庫移植也帶來了困難。 “ 依賴注入 ” 的功能通常是用專門的 IoC 容器提供的，在 Java 平臺下，這樣的容器包括 Spring， PicoContainer 等。不過，在 Petshop 系統(tǒng)中，并不需要專門的容器來實現(xiàn) “ 依賴注入 ” ，簡單的做法 還是利用配置文件和反射功能來實現(xiàn)。然而，當(dāng)我們利用配置文件和反射功能時， 并不需要 具體工廠的創(chuàng)建，我們完全可以在配置文件中，直接指向具體的數(shù)據(jù)庫對象實現(xiàn)類，例如 。 層。因為數(shù)據(jù)庫類型的不同，對數(shù)據(jù)庫的操作也有所不同，代碼也會因 此有所區(qū)別 [14]。 圖 業(yè)務(wù)邏輯層的模塊結(jié)構(gòu)圖 20 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) 層。在業(yè)務(wù)邏輯層中，不能直接訪問數(shù)據(jù)庫，而必須通過 數(shù)據(jù)訪問層。既然與具體的數(shù)據(jù)訪問邏輯無關(guān)， 那么 層與層之間的關(guān)系就是松散耦合的。畢竟，具體實現(xiàn)的 SQLServerDAL 和 OracalDAL 與業(yè)務(wù)邏輯層沒有 任何 關(guān)系。 設(shè)計模式的應(yīng)用是為了實現(xiàn)軟件設(shè)計中的幾個原則，其中一個重要原則是：減 少模塊之間的耦合程度。 設(shè)計的時候只關(guān)心類的接口，編程的時候可以先實現(xiàn)一個簡單的接口，供別的模塊調(diào)用。 工廠模式 ， 應(yīng)用于 “ 一系列相互依賴的對象 ” 的創(chuàng)建工作，以適應(yīng)需求的變化 ： DALFactory：數(shù)據(jù)訪問層的抽象工廠（ 通過依賴注入 決定創(chuàng)建哪種數(shù)據(jù)庫類型的數(shù)據(jù)訪問層。 依賴注入是指將應(yīng)用程序的組件在運行時注入給應(yīng)用中。 CacheDependencyFactory：緩存依賴類的工廠類。 MessagingFactory：異時處理消息隊列的抽象工廠（反射創(chuàng)建具體的異時處理類） 。 ： IorderStrategy。 第三章 系統(tǒng)架構(gòu)設(shè)計 21 本 系統(tǒng) 架構(gòu)設(shè)計 策略 本系統(tǒng) 是 在 Petshop 項目架構(gòu)設(shè)計的基礎(chǔ)上，立足于本系統(tǒng)項目的實際情況和特點，在其基礎(chǔ)上進行部分精簡和修改 得到的 ，比如減少了緩存依賴和策略模式的應(yīng)用等等 。 項目依賴關(guān)系 Web 引用 BLL。 IDAL 引用 Model。 DALFactory 引用 IDAL，通過讀取 里設(shè)置的程序集，加載類的實例，返回給 BLL 使用。 實現(xiàn)步驟 創(chuàng)建 Model，實現(xiàn)業(yè)務(wù)實體。 創(chuàng)建 SQLServerDAL，實現(xiàn)接口里的方法。 創(chuàng)建 DALFactory，返回程序集的指定類的實例。 創(chuàng)建 WEB，調(diào)用 BLL 里的數(shù)據(jù)操作方法。它 為交流面向?qū)ο蟮脑O(shè)計中的需求、行為、體系結(jié)構(gòu)和實現(xiàn)提供了一套綜合的表示法并提供了一種創(chuàng)建和記錄系統(tǒng)模型的方法。 UML 由 9 個不同類型的圖組成，每種圖都著重于使用不同的方法來分析并定義系統(tǒng)。 活動圖顯示了系統(tǒng)行為的詳細描述 ， 描述了單個功能需求內(nèi)部的細節(jié)行為，包括基本的場景和一些可選的場景。 組件圖顯示了系統(tǒng)的體系結(jié)構(gòu)， 描述了系統(tǒng)的可部署單元 (可執(zhí)行文件、組件、數(shù)據(jù)存儲和其他一些內(nèi)容 )以及一些接口，可部署單元通過這些接口進行交互。 順序圖顯示了對象隨著時間的交互， 描述了某個功能需求的路徑或場景內(nèi)相對時間的詳細行為。 類圖顯示了類定義和關(guān)系， 描述了系統(tǒng)設(shè)計中的類和接口，以及它們之間的關(guān)系。 包圖顯示了設(shè)計的層次結(jié)構(gòu)， 描述了設(shè)計的相關(guān)元素如何按組結(jié)合在一起，以及這些組如何相互依賴。 這些圖對于組織許多不同類型的元素將非常有用。 24 基于 C+SQL Server 的 B/S結(jié)構(gòu)水費管理系統(tǒng) 基于 UML 與 精簡 RUP 的面向?qū)ο蠼：喗? 傳統(tǒng)的軟件開發(fā)是從算法的角度進行建模。這種觀點導(dǎo)致開發(fā)人員把精力集中于控制流程和對大的算法進行分解。當(dāng)需求發(fā)生變化（總會變 化的）以及系統(tǒng)增長（總會增長的）時，用這種方法建造的系統(tǒng)就會變得很難維護。按照這種方法，所有軟件系統(tǒng)都用對象或類作為其主要構(gòu)造塊。每一個對象都有標(biāo)識（能夠?qū)λ?，以區(qū)別于其他對象）、狀態(tài)（通常有一些數(shù)據(jù)與它相聯(lián)系）和行為（能對該對象做某些事，它也能為其他對象做某些事）。行 之有效的軟件過程可以提高開發(fā)軟件組織的生產(chǎn)效率、提高軟件質(zhì)量、降低成本并減少風(fēng)險。 對高質(zhì)量軟件的追求是過程發(fā)展的原動力。 UML 在很大程度上是獨立于過程的，這意味著它不依賴于任何特殊的軟件開發(fā)生命周期。而我們這里采用的就是 RUP。它 是一種特別適應(yīng)于 UML的生命周期方法，是有效使用 UML的指南，與早期的瀑布式開發(fā)模型相比，它具有迭代式的增量開發(fā)、使用實例驅(qū)動、以軟件體系結(jié)構(gòu)為核心 3個鮮明特點，這使得 RUP非常適宜于開發(fā)復(fù)雜、技術(shù)難度大、需求多變、高風(fēng)險的項目。 第四章 系統(tǒng)分析與設(shè)計 25 RUP 可以用二維坐