系統(tǒng)的層次劃分

第二章系統(tǒng)的層次劃分.簡(jiǎn)述N層的應(yīng)用軟件系統(tǒng)，由于其眾多的優(yōu)點(diǎn)，已經(jīng)成為典型的軟件系統(tǒng)架構(gòu)，也已經(jīng)為廣大開發(fā)人員所熟知。在一個(gè)典型的三層應(yīng)用軟件系統(tǒng)中，應(yīng)用系統(tǒng)通常被劃分成以下三個(gè)層次：數(shù)據(jù)庫層、應(yīng)用服務(wù)層和用戶界面層。如下圖（圖2.1）所示：圖2.1其中，應(yīng)用服務(wù)層集中了系統(tǒng)的業(yè)務(wù)邏輯的處理，因此，可以說是應(yīng)用軟件系統(tǒng)中的核心部分。軟件系統(tǒng)的健壯性、靈活性、可重用性、可升級(jí)性和可維護(hù)性，在很大程度上取決于應(yīng)用服務(wù)層的設(shè)計(jì)。因此，如何構(gòu)建一個(gè)良好架構(gòu)的應(yīng)用服務(wù)層，是應(yīng)用軟件開發(fā)者需要著重解決的問題。為了使應(yīng)用服務(wù)層的設(shè)計(jì)達(dá)到最好的效果，我們通常還需要對(duì)應(yīng)用服務(wù)層作進(jìn)一步的職能分析和層次細(xì)分。很多開發(fā)者在構(gòu)建應(yīng)用服務(wù)層的時(shí)候，把數(shù)據(jù)庫操縱、業(yè)務(wù)邏輯處理甚至界面顯示夾雜在一起，或者，把業(yè)務(wù)邏輯處理等同于數(shù)據(jù)庫操縱，等等，這些，都是有缺陷的做法。我們將就在這個(gè)方面進(jìn)行設(shè)計(jì)時(shí)可采用的方案進(jìn)行一些探討。在一個(gè)分布式應(yīng)用系統(tǒng)中，整個(gè)系統(tǒng)會(huì)部署在不同的物理設(shè)備上，如上面所示的三層體系，用戶界面和應(yīng)用服務(wù)器可能在不同的設(shè)備上，這就涉及到不同機(jī)器之間的通信問題，也就是層間的通信和交互問題。我們已經(jīng)有了很多可以用于分布式遠(yuǎn)程訪問的技術(shù)，如CORBA，4Java平臺(tái)上，我們還有JavaRMI、EJB,在Windows平臺(tái)上，從DCOM到COM+,再到.Net下的WebService和.NetRemoting等。如何選用合適的遠(yuǎn)程訪問技術(shù)，也是我們?cè)谙到y(tǒng)框架中需要考慮的問題。為了使討論更具有針對(duì)性，本文也會(huì)討論一些比較流行的系統(tǒng)架構(gòu)，例如J2EE架構(gòu)，以及JDO,然后，我們會(huì)討論Websharp在這個(gè)方面的一些設(shè)計(jì)理念。,設(shè)計(jì)的原則和評(píng)判標(biāo)準(zhǔn)同軟件工程的原則一樣，應(yīng)用服務(wù)層的設(shè)計(jì)，必須遵循的最重要的原則就是高內(nèi)聚和低耦合。軟件分層的本來目的，就是提高軟件的可維護(hù)性和可重用性，而高內(nèi)聚和低耦合正是達(dá)成這一目標(biāo)必須遵循的原則。盡量降低系統(tǒng)各個(gè)部分之間的耦合度，是應(yīng)用服務(wù)層設(shè)計(jì)中需要重點(diǎn)考慮的問題。內(nèi)聚和耦合，包含了橫向和縱向的關(guān)系。功能內(nèi)聚和數(shù)據(jù)耦合，是我們需要達(dá)成的目標(biāo)。橫向的內(nèi)聚和耦合，通常體現(xiàn)在系統(tǒng)的各個(gè)模塊、類之間的關(guān)系，而縱向的耦合，體現(xiàn)在系統(tǒng)的各個(gè)層次之間的關(guān)系。系統(tǒng)的框架，通常包含了一系列規(guī)范、約定和支撐類庫、服務(wù)。對(duì)于如何判斷一個(gè)軟件的系統(tǒng)框架的優(yōu)劣，筆者認(rèn)為，可以從以下幾個(gè)方面來評(píng)判：系統(tǒng)的內(nèi)聚和耦合度這是保證一個(gè)系統(tǒng)的架構(gòu)是否符合軟件工程原則的首要標(biāo)準(zhǔn)。層次的清晰和簡(jiǎn)潔性系統(tǒng)每個(gè)部分完成功能和目標(biāo)必須是明確的，同樣的功能，應(yīng)該只在一個(gè)地方實(shí)現(xiàn)。如果某個(gè)功能可以在系統(tǒng)不同的地方實(shí)現(xiàn)，那么，將會(huì)給后來的開發(fā)和維護(hù)帶來問題。系統(tǒng)應(yīng)該簡(jiǎn)單明了，過于復(fù)雜的系統(tǒng)架構(gòu)，會(huì)帶來不必要的成本和維護(hù)難度。在盡可能的情況下，一個(gè)部分應(yīng)該完成一個(gè)單獨(dú)并且完整的功能。易于實(shí)現(xiàn)性如果系統(tǒng)架構(gòu)的實(shí)現(xiàn)非常困難，甚至超出團(tuán)隊(duì)現(xiàn)有的技術(shù)能力，那么，團(tuán)隊(duì)不得不花很多的精力用于架構(gòu)的開發(fā)，這對(duì)于整個(gè)項(xiàng)目來說，可能會(huì)得不償失。簡(jiǎn)單就是美?？缮?jí)和可擴(kuò)充性一個(gè)系統(tǒng)框架，受設(shè)計(jì)時(shí)技術(shù)條件的限制，或者設(shè)計(jì)者本人對(duì)系統(tǒng)認(rèn)識(shí)的局限，可能不會(huì)考慮到今后所有的變化。但是，系統(tǒng)必須為將來可能的變化做好準(zhǔn)備，能夠在今后，在目前已有的基礎(chǔ)上進(jìn)行演進(jìn)，但不會(huì)影響原有的應(yīng)用。接口技術(shù)，是在這個(gè)方面普遍應(yīng)用的技巧。是否有利于團(tuán)隊(duì)合作開發(fā)一個(gè)好的系統(tǒng)架構(gòu)，不僅僅只是從技術(shù)的角度來看，而且，它還應(yīng)該適用于團(tuán)隊(duì)開發(fā)模型，可以方便一個(gè)開發(fā)團(tuán)隊(duì)中各個(gè)不同角色的互相協(xié)作。例如，將Web頁面和業(yè)務(wù)邏輯組件分開，可是使頁面設(shè)計(jì)人員和程序員的工作分開來同步進(jìn)行而不會(huì)互相影響。性能性能對(duì)于軟件系統(tǒng)來說是很重要的，但是，有的時(shí)候，為了能讓系統(tǒng)得到更大的靈活性，可能不得不在性能和其他方面取得平衡。另外一個(gè)方面，由于硬件技術(shù)的飛速發(fā)展和價(jià)格的下降，性能的問題往往可以通過使用使用更好的硬件來獲得提升。3,應(yīng)用服務(wù)層的內(nèi)容應(yīng)用服務(wù)層，通常也被稱為業(yè)務(wù)邏輯層，因?yàn)檫@一層，是應(yīng)用軟件系統(tǒng)業(yè)務(wù)邏輯處理集中的部分。然而，我將這一層稱為應(yīng)用服務(wù)層，而不稱業(yè)務(wù)邏輯層，因?yàn)椋@一層需要處理的不僅僅是業(yè)務(wù)邏輯，還包含了其他方面的內(nèi)容。從完整的角度來說，應(yīng)用服務(wù)層需要處理以下內(nèi)容：數(shù)據(jù)的表示方式數(shù)據(jù)，是軟件處理的對(duì)象。從某種程度上來說，”軟件，就是數(shù)據(jù)結(jié)構(gòu)加算法”的說法，是有一定意義的。在面向?qū)ο蟮南到y(tǒng)中，數(shù)據(jù)是用類來表示的，代表了現(xiàn)實(shí)世界實(shí)體對(duì)象在軟件系統(tǒng)中的抽象?？紤]所謂的MVC模式，這個(gè)部分的類屬于M--實(shí)體類的范疇。由于應(yīng)用軟件通常會(huì)使用數(shù)據(jù)庫，數(shù)據(jù)庫中的數(shù)據(jù)，可以看成是對(duì)象的持久化保存。由于數(shù)據(jù)庫一般是關(guān)系型的，因此，這個(gè)部分，還需要考慮類（對(duì)象）同關(guān)系型數(shù)據(jù)的映射，即通常所說的O-RMAP問題。數(shù)據(jù)的存取方式如同上述所說，軟件系統(tǒng)處理的實(shí)體對(duì)象數(shù)據(jù)需要持久化保存數(shù)據(jù)庫中，因此，我們必須處理系統(tǒng)同數(shù)據(jù)庫的交互，以及數(shù)據(jù)的存取和轉(zhuǎn)換方式的問題。業(yè)務(wù)邏輯的組織方式在面向?qū)ο蟮南到y(tǒng)中，業(yè)務(wù)邏輯表現(xiàn)為對(duì)象之間的交互。有了上述的實(shí)體對(duì)象，以及對(duì)象的保存策略，就可以將這些對(duì)象組合起來，編寫我們的業(yè)務(wù)邏輯處理程序。在業(yè)務(wù)邏輯的處理中，必須保證處理的正確性和完整性，這將會(huì)涉及到事務(wù)處理。通常，我們也會(huì)把業(yè)務(wù)邏輯封裝成組件的形式，以得到最大的可重用性。業(yè)務(wù)服務(wù)的提供方式在我們完成系統(tǒng)的功能后，如何向客戶提供服務(wù)，是我們需要考慮的問題。這里的客戶，不僅僅是指軟件的使用者，也包括調(diào)用的界面、其他程序等。例如，在一個(gè)基于Web的ASP.Net或JSP系統(tǒng)中，業(yè)務(wù)邏輯功能的客戶便是這些ASP.Net頁面或JSP頁面。業(yè)務(wù)邏輯組件應(yīng)該通過什么方式，直接的，或間接的，向這些客戶提供服務(wù),是這一層需要完成的任務(wù)。層的部署和層間交互對(duì)于一個(gè)多層的應(yīng)用軟件系統(tǒng)來說，尤其是大型的應(yīng)用軟件系統(tǒng)，通常需要把不同的部分部署在不同的邏輯或物理設(shè)備上。特別是一些基于Web的應(yīng)用軟件系統(tǒng)，其部署工作將涉及到Web服務(wù)器、組件服務(wù)器、數(shù)據(jù)庫服務(wù)器等不同的服務(wù)設(shè)備。在進(jìn)行應(yīng)用軟件架構(gòu)的設(shè)計(jì)的時(shí)候，必須考慮各種不同的部署方案。當(dāng)系統(tǒng)需要進(jìn)行分布式訪問的時(shí)候，如何統(tǒng)一和簡(jiǎn)化分布式系統(tǒng)的開發(fā)，便成了系統(tǒng)框架需要考慮的內(nèi)容。綜上所述，一個(gè)完整的基于Web的應(yīng)用軟件系統(tǒng)，其架構(gòu)可以用圖2.2來表示（Websharp的應(yīng)用軟件系統(tǒng)架構(gòu)）：

Entity(0/RM]0RH3Entity(0/RM]0RH3圖2.2對(duì)于以上各個(gè)方面來說，每個(gè)問題都可以有很多種策略和方案，但是，在一個(gè)系統(tǒng)中，應(yīng)該盡可能的統(tǒng)一這些策略和方案。也就是說，在一個(gè)系統(tǒng)，或者一個(gè)項(xiàng)目中，應(yīng)該統(tǒng)一每個(gè)解決每個(gè)問題所采用的方法。軟件的開發(fā)方法是靈活的，可以用不同的方法解決相同的問題，這會(huì)誘使開發(fā)人員采用他們認(rèn)為能夠表現(xiàn)自己的方法，但是，從整個(gè)系統(tǒng)來看，這將會(huì)是災(zāi)難性的。我們應(yīng)該盡可能統(tǒng)一，就是，采用統(tǒng)一的數(shù)據(jù)表示方式、統(tǒng)一的數(shù)據(jù)存取方式、統(tǒng)一的業(yè)務(wù)邏輯處理方式等。下面，將就這些部分的設(shè)計(jì)策略和可用方案進(jìn)行一些比較詳細(xì)的論述。4,數(shù)據(jù)實(shí)體的表示應(yīng)用軟件系統(tǒng)，從本質(zhì)上來說，是計(jì)算機(jī)對(duì)現(xiàn)實(shí)世界的模擬?，F(xiàn)實(shí)世界中的實(shí)體對(duì)象，在軟件系統(tǒng)中，表現(xiàn)為需要處理的數(shù)據(jù)。在面向?qū)ο蟮南到y(tǒng)中，這是通過“類“和“對(duì)象”來表示的。參考著名的"MVC”模式，類可以分成實(shí)體類（M）、控制類（C）、和邊界類（V），分別代表了實(shí)體對(duì)象、控制和界面顯示。系統(tǒng)中需要處理的數(shù)據(jù)，在面向?qū)ο蟮南到y(tǒng)中，屬于實(shí)體類部分。在考慮數(shù)據(jù)實(shí)體層的設(shè)計(jì)策略的時(shí)候，需要把握以下要點(diǎn)：一致的數(shù)據(jù)表示方式。在一個(gè)系統(tǒng)中，數(shù)據(jù)的表示方式必須盡可能統(tǒng)一，同時(shí)，在處理單個(gè)數(shù)據(jù)和多個(gè)數(shù)據(jù)的時(shí)候，處理方式盡可能一致。因?yàn)閿?shù)據(jù)通常是需要存儲(chǔ)到數(shù)據(jù)庫中，因此，良好的映射方法是必需的。處理好對(duì)象的粒度，即所謂的粗粒度對(duì)象、細(xì)粒度對(duì)象。

一般例子考慮一個(gè)現(xiàn)實(shí)的例子，一個(gè)倉(cāng)庫中的產(chǎn)品（Product）,在系統(tǒng)中可以使用如下定義：我們盡量將問題簡(jiǎn)化了。如前所述，我們希望在處理單個(gè)對(duì)象和對(duì)象集合的時(shí)候，處理的方式盡量統(tǒng)一，這對(duì)于軟件開發(fā)的意義是很大的。常用的處理對(duì)象集合的方法有：數(shù)組表示的方法例如，上面的例子中當(dāng)一張入庫單包含多條入庫單明細(xì)的時(shí)候采用的方法。為了靈活性，也可以使用容器來，如Java中的Vector或C#的ArrayList(C#)。只是，在處理對(duì)象的時(shí)候，需要一個(gè)類型轉(zhuǎn)換的操作。這個(gè)問題，在支持泛型的語言中不會(huì)存在，如使用C++的標(biāo)準(zhǔn)庫的容器類。ObjectCollection方法。這個(gè)方法同上面的方法類似，不同之處在于，為每個(gè)實(shí)體類設(shè)計(jì)一個(gè)Collection類。例如，可以為FormDetail設(shè)計(jì)一個(gè)FormDetailsCollection類(C#)：publicclassFormDetailsCollection:ArrayList(publicvoidAdd(FormDetaildetail)(base.Add(detail);publicnewFormDetailthis[intnIndex]getreturn(FormDetail)base[nIndex];這么做的好處在于，在操作集合中的對(duì)象時(shí)，不必進(jìn)行類型轉(zhuǎn)換的操作。數(shù)據(jù)集的表示方法。采用這種方法，通常是直接把從數(shù)據(jù)庫查詢中獲取的數(shù)據(jù)集(Recordset)作為數(shù)據(jù)處理對(duì)象。這種方法在ASP應(yīng)用程序中是非常常見的做法。這種做法簡(jiǎn)單，初學(xué)者很容易掌握，但是他不是一種面向?qū)ο蟮姆椒ǎ撞∫埠芏?。EJB的方法在J2EE體系中，對(duì)實(shí)體對(duì)象的處理的典型方法是EntityBean。J2EE中使用EntityBean來表示數(shù)據(jù)，以及封裝數(shù)據(jù)的持久化儲(chǔ)存(同數(shù)據(jù)庫的交互)。由于EntityBean比較消耗資源，而且采用的是遠(yuǎn)程調(diào)用的方式來訪問，因此，在需要傳遞大量數(shù)據(jù)，或者在不同的層次之間傳遞數(shù)據(jù)的時(shí)候，往往還會(huì)采用一些諸如“值對(duì)象”(ValueObject)的設(shè)計(jì)模式來提升性能。關(guān)于J2EE中的設(shè)計(jì)模式的更多內(nèi)容，讀者可以參考《J2EE核心模式》一書。JDO的方法相對(duì)于J2EE這個(gè)昂貴的方法來說，JDO提供了一個(gè)相對(duì)“輕量級(jí)”的方案。在JDO中，你可以采用一般的做法，編寫實(shí)體類，然后，通過一些強(qiáng)化器對(duì)這些類進(jìn)行強(qiáng)化，以使其符合JDO的規(guī)范，最后，你可以通過PersistenceManager來實(shí)現(xiàn)對(duì)象的持久化儲(chǔ)存。無論是EJB還是JDO,在同數(shù)據(jù)庫進(jìn)行映射的時(shí)候，都選用了XML配置文件的方式。這是一種靈活的方式。由于XML強(qiáng)大的表達(dá)能力，我們可以很好的用它來描述代碼中的實(shí)體類和數(shù)據(jù)庫之間的映射關(guān)系，并且，不用在代碼中進(jìn)行硬編碼，這樣，在情況發(fā)生變化的時(shí)候，有可能只需要修改配置文件，而不用去修改程序的源代碼。關(guān)于EJB和JDO的配置文件的更多的信息，各位可以參考相關(guān)的文檔，這里不再贅述了。然而，使用XML配置文件的方式并不是唯一的方法，在微軟提供的一些案例中，如Duwamish示例，就沒有采用這種方式。至于開發(fā)人員在開發(fā)過程中具體采用哪種方式，是需要根據(jù)具體情況進(jìn)行權(quán)衡和取舍的。Websharp的方法Websharp在數(shù)據(jù)的表現(xiàn)上，充分利用了.11Framework類庫中DataSet和特性(Attribute)的功能。我們?cè)O(shè)計(jì)了一個(gè)EntityData類，這個(gè)類繼承了DataSet，并增加了一些屬性和方法。在Websharp中，當(dāng)表示一個(gè)實(shí)體類的時(shí)候，需要定義一個(gè)抽象類，這個(gè)抽象類繼承PersistenceCapable。例如，一個(gè)Schdule類可以表示如下：[TableMap("Schdule","GUID")][WebsharpEntityInclude(typeof(Schdule))]publicabstractclassSchdule:PersistenceCapable([ColumnMap("GUID”,DbType.String,"")]publicabstractstringGUID{get;set;}[ColumnMap("UserID”,DbType.String,"")]publicabstractstringUserID{get;set;}[ColumnMap("StartTime”,DbType.DateTime)]publicabstractDateTimeStartTime{get;set;}[ColumnMap("EndTime”,DbType.DateTime)]publicabstractDateTimeEndTime{get;set;}[ColumnMap("Title”,DbType.String,"")]publicabstractstringTitle{get;set;}[ColumnMap("Description”,DbType.String,"")]publicabstractstringDescription{get;set;}[ColumnMap("RemidTime”,DbType.DateTime)]publicabstractDateTimeRemidTime{get;set;}[ColumnMap("AddTime”,DbType.DateTime)]publicabstractDateTimeAddTime{get;set;}[ColumnMap("Status”,DbType.Int16,0)]publicabstractshortStatus{get;set;}}類的TableMap特性指明了同Schdule實(shí)體類相映射的數(shù)據(jù)庫表，以及關(guān)鍵字，ColumnMap特性指明了同某個(gè)屬性相映射的數(shù)據(jù)庫表字段，以及數(shù)據(jù)類型和默認(rèn)值。在實(shí)際的應(yīng)用中，定義了這樣一個(gè)Schdule抽象類后，要獲取一個(gè)實(shí)體對(duì)象，因?yàn)镾chdule類是抽象的，所以你不可以直接使用new操作來初始化Schdule對(duì)象，應(yīng)當(dāng)通過如下方式取得：Schduleschdule=EntityManager.CreateObject(typeof(Schdule))asSchdule;EntityManager會(huì)即時(shí)編譯出一個(gè)Schdule的實(shí)現(xiàn)類，并且返回一個(gè)對(duì)象。在這種方式下，實(shí)體類同數(shù)據(jù)庫表的映射是通過Attribute來實(shí)現(xiàn)的。可以使用另外一種方法來表示一個(gè)實(shí)體類。在這種方式下，需要編寫一個(gè)XML映射文件，然后，可以使用如下方式取得一個(gè)實(shí)體對(duì)象：EntityDataschdule=EntityManager.GetEntityData("Schdule");然后，可以通過如下方式來訪問這個(gè)對(duì)象的屬性：stringTitle=schdule["Title"]可以看到，這種方式同傳統(tǒng)的方式有點(diǎn)不同。在這種方式下，數(shù)據(jù)的表現(xiàn)形式只有一個(gè)，那就是EntityData。其好處是明顯的，不用為每個(gè)實(shí)體都單獨(dú)編寫一個(gè)類，能夠大大減少代碼的編寫量。其缺點(diǎn)也很明顯，那就是不能利用編譯器類型檢測(cè)的功能，如果在調(diào)用對(duì)象的屬性的時(shí)候，寫錯(cuò)了屬性的名稱，就可能出錯(cuò)，這需要更加仔細(xì)的測(cè)試工作。但是，這個(gè)問題可以通過工具生成代碼來解決。.數(shù)據(jù)的存取方式數(shù)據(jù)存取的目的，是持久化保存對(duì)象，以備后來的使用，如查詢、修改、統(tǒng)計(jì)分析等。存取的對(duì)象，可以是數(shù)據(jù)庫、普通文件、XML甚至其他任何方式，只要保證數(shù)據(jù)能夠長(zhǎng)久保存，并且，不會(huì)受斷電、系統(tǒng)重起等因素的影響。在這個(gè)部分，最理想的狀況，自然是能夠支持除了數(shù)據(jù)庫以外的各種類型的存取方式，或者，至少留有接口，能夠比較方便的擴(kuò)充。因?yàn)閿?shù)據(jù)庫是最常用，也是最有效的數(shù)據(jù)存儲(chǔ)方法，因此，支持?jǐn)?shù)據(jù)庫存儲(chǔ)是最首先必須支持的。在不同的平臺(tái)下，有不同的數(shù)據(jù)庫訪問的手段。例如，在Java平臺(tái)下，有」口3。，在Windows平臺(tái)下，可以使用ADO、ADO.Net等。但是，這些手段還比較接近底層，在實(shí)際操縱數(shù)據(jù)庫的時(shí)候，需要編寫大量的代碼，并且，我們還需要通過手工的方式來完成將程序中的面向?qū)ο蟮臄?shù)據(jù)存儲(chǔ)到關(guān)系型數(shù)據(jù)庫的工作。這么做，自然編程的效率不高，并且非常容易出錯(cuò)。但是，不可否認(rèn)，這也是一種可以選用的方式。從另外一個(gè)方面來看，由于我們前面已經(jīng)解決了數(shù)據(jù)的映射問題，因此，在數(shù)據(jù)的存取方面是非常有規(guī)律的，我們完全可以讓這個(gè)工作通過框架來執(zhí)行。這樣，我們一方面可以簡(jiǎn)化很多同數(shù)據(jù)庫交互方面的代碼編寫工作量，能夠減少出現(xiàn)Bug的幾率，另一方面，由于框架封裝了不同數(shù)據(jù)庫之間的差異，使得我們?cè)诰帉懗绦虻臅r(shí)候，不用考慮不同數(shù)據(jù)庫之間的差異，而將這個(gè)工作交給框架去做，實(shí)現(xiàn)軟件的后臺(tái)數(shù)據(jù)庫無關(guān)性。在這個(gè)部分，以下兩個(gè)部分的類會(huì)顯得特別重要：?對(duì)象--關(guān)系映射的分析類，能夠通過既定的方案完成對(duì)象--關(guān)系的映射，確定數(shù)據(jù)存取方案?數(shù)據(jù)庫操縱類：根據(jù)映射關(guān)系，將數(shù)據(jù)準(zhǔn)確的存儲(chǔ)到數(shù)據(jù)庫中，并且封裝不同數(shù)據(jù)庫之間的差異。這個(gè)部分的操作過程，可以用圖（圖2.3）大概的表示如下：圖2.3在J2EE中，這個(gè)部分比較典型的就是EntityBean中的CMP。由于在BMP中，同數(shù)據(jù)庫的交互部分需要通過手工編寫代碼的方式來實(shí)現(xiàn)，因此，很難享受到容器帶來的便利，只是由于EJB2.0以前的標(biāo)準(zhǔn)，CMP的功能，包括映射能力、實(shí)體關(guān)系模式等方面的功能比較弱，所以，在很多時(shí)候，我們不得不使用BMP?，F(xiàn)在，EJB2.0，在這個(gè)方面的功能已經(jīng)非常強(qiáng)大了，我們完全可以享受容器帶來的便利，而將大部分精力放在實(shí)現(xiàn)更加復(fù)雜的業(yè)務(wù)邏輯方面了。在JDO中，您同樣可以通過PersistenceManager來實(shí)現(xiàn)同樣的目標(biāo)，例如，您想把一個(gè)Customer對(duì)象保存到數(shù)據(jù)庫中，可以采用類似于下面的代碼:Schduleschdule=newSchdule( );PersistenceManagerPM=PMFactory.initialize( );Pm.persist(schdule);代碼同樣非常簡(jiǎn)明和直觀，沒有一大堆數(shù)據(jù)庫操縱的代碼，也不容易發(fā)生差錯(cuò)。Websharp的方案同JDO類似，Websharp定義了PersistenceManager接口，這個(gè)接口的定義在后面的章節(jié)中會(huì)給出，這里，我們先看看其使用方式。當(dāng)我們有了某個(gè)實(shí)體對(duì)象后，需要保存到數(shù)據(jù)庫中的時(shí)候，我們可以使用下面的代碼來實(shí)現(xiàn)：在這個(gè)部分，另外需要注意的是，為了保證數(shù)據(jù)存儲(chǔ)的完整性，應(yīng)當(dāng)考慮事務(wù)處理的功能。J2EE、JDO和Websharp都支持在數(shù)據(jù)存儲(chǔ)的時(shí)候使用事務(wù)處理。在Websharp中，通過Transaction接口，提供了基本的事務(wù)處理能力。上面的代碼，如果需要使用事務(wù)處理，則可以修正如下：publicboolAddSchdule(Schduleschdule)(if(!CheckSchdule(schdule))returnfalse;PersistenceManagerpm=PersistenceManagerFactory.Instance().CreatePersistenceManager();Transactiontrans=pm.CurrentTransaction;trans.Begin();try(pm.PersistNewObject(schdule);trans.Commit();returntrue;.業(yè)務(wù)邏輯的處理有了上面的工作，我們就可以把這些對(duì)象組合起來，編寫我們的業(yè)務(wù)邏輯。在面向?qū)ο蟮南到y(tǒng)中，業(yè)務(wù)邏輯表現(xiàn)為對(duì)象之間的交互。在一些簡(jiǎn)單的系統(tǒng)中，沒有復(fù)雜的業(yè)務(wù)邏輯，只是一些數(shù)據(jù)的維護(hù)工作，那么，有了上面兩個(gè)部分的工作，我們實(shí)際上可能已經(jīng)忘成了大部分的工作。在這個(gè)部分，由于不同系統(tǒng)之間業(yè)務(wù)邏輯千差萬別，基本上沒有辦法提供統(tǒng)一的模式。但是，應(yīng)當(dāng)注意的是，在同一個(gè)系統(tǒng)中，采用基本一致的策略是非常必要的，這有助于消除項(xiàng)目?jī)?nèi)部的不一致性，使項(xiàng)目更加可控。甚至于，這些策略可以擴(kuò)展成公司部分、甚至所有項(xiàng)目的策略。值得指出的是，很多人在這個(gè)部分操縱數(shù)據(jù)庫，把業(yè)務(wù)邏輯處理等同于數(shù)據(jù)庫操作，這是不可取的。在業(yè)務(wù)邏輯處理中，處理的應(yīng)該是對(duì)象，而不是直接同數(shù)據(jù)庫打交道，這樣，才能獲得更好的系統(tǒng)結(jié)構(gòu)。在業(yè)務(wù)邏輯處理部分，由框架提供一些支撐的服務(wù)是非常必要的。這其中，最重要的一點(diǎn)就是事務(wù)的處理。業(yè)務(wù)邏輯的處理過程，會(huì)涉及到多個(gè)對(duì)象之間的交互，以及多次同數(shù)據(jù)庫的交互。為了保證處理過程的完整性，必須使用事務(wù)處理的方法?？蚣鼙仨氈С质聞?wù)處理。事務(wù)處理的功能，基本上有兩種選擇：使用基于數(shù)據(jù)庫連接的事務(wù)、使用外部事物處理服務(wù)。使用基于數(shù)據(jù)庫連接的事務(wù)，事務(wù)處理的性能相對(duì)比較高，但是，當(dāng)系統(tǒng)涉及到多個(gè)數(shù)據(jù)庫之間的交互時(shí)，基于數(shù)據(jù)庫連接的事務(wù)便無能為力了。而使用專用的事務(wù)處理服務(wù)，能夠適應(yīng)更多的情況，并且，有測(cè)試表明，隨著數(shù)據(jù)處理量的上升，兩者之間的性能差異會(huì)逐漸減小。在J2EE中，容器提供了事務(wù)處理的能力。在.Net平臺(tái)上，事務(wù)處理是通過WindowsCOM+服務(wù)來提供的。在Websharp中，如上面所講，通過Transaction接口，提供了基本的事務(wù)處理能力，能夠滿足大部分事務(wù)處理的要

求。當(dāng)Websharp提供的事務(wù)處理能力不能滿足需求的時(shí)候，可以使用EnterpriseService。下面是一個(gè)簡(jiǎn)單的例子:publicboolAddSchdule(Schduleschdule,string[]otherPeoples)(if(!CheckSchdule(schdule))returnfalse;PersistenceManagerpm=PersistenceManagerFactory.Instance().CreatePersistenceManager();Transactiontrans=pm.CurrentTransaction;trans.Begin();try(pm.PersistNewObject(schdule);foreach(stringotherPeopleinotherPeoples)(Schdules=EntityManager.CreateObject(typeof(Schdule))asSchdule;s.GUID=Guid.NewGuid().ToString();s.UserID=otherPeople;s.StartTime=schdule.StartTime;s.EndTime=schdule.StartTime;s.Title=schdule.Title;s.Description=schdule.Description;s.RemidTime=schdule.RemidTime;s.AddTime=DateTime.Now;s.Status=0;s.Status=0;pm.PersistNewObject(s);在業(yè)務(wù)邏輯這一層，另外一個(gè)需要關(guān)注的問題是所謂的AOP。關(guān)于AOP的內(nèi)容，我們會(huì)在下面的章節(jié)中再討論。,業(yè)務(wù)服務(wù)的提供業(yè)務(wù)外觀層(BusinessFacade)的目的，是隔離系統(tǒng)功能的提供者和使用者，更明確地說，是隔離業(yè)務(wù)邏輯的軟件的用戶界面(可以參見Facade設(shè)計(jì)模式)。這一層沒有任何需要處理的邏輯，只是作為后臺(tái)邏輯處理和前端用戶界面的緩沖區(qū)，以達(dá)到如下目的將用戶界面和系統(tǒng)業(yè)務(wù)邏輯處理分開，這樣，當(dāng)業(yè)務(wù)邏輯發(fā)生變化時(shí)，不用修改客戶端程序，是一種支持變化的設(shè)計(jì)方法。使同一個(gè)業(yè)務(wù)邏輯能夠處理不同的客戶端請(qǐng)求。例如，可以將Facade設(shè)計(jì)成WebService，這樣，可以同時(shí)為傳統(tǒng)的WinForm客戶端程序、Web程序以及其他外部系統(tǒng)提供服務(wù)，而使用相同的應(yīng)用服務(wù)層，同時(shí)，也可以實(shí)現(xiàn)系統(tǒng)的分布式部署。關(guān)于如何做到這一點(diǎn)，可以參見loffice的Demo程序。作為系統(tǒng)不同模塊之間的調(diào)用接口。一個(gè)系統(tǒng)通常會(huì)包含很多模塊，這些模塊相對(duì)獨(dú)立，又可能互相調(diào)用。為了減少各個(gè)不同部分之間的耦合度，必須采用一定的設(shè)計(jì)方法，F(xiàn)acade設(shè)計(jì)模式就是非常有效的一種，也是業(yè)務(wù)外觀層的基礎(chǔ)。?有利于項(xiàng)目團(tuán)隊(duì)的分工協(xié)作。業(yè)務(wù)外觀層作為一個(gè)訪問接口，將界面設(shè)計(jì)人員和邏輯設(shè)計(jì)人員分開，使得系統(tǒng)的開發(fā)可以實(shí)現(xiàn)縱向的分工，不同的開發(fā)人員可以關(guān)注自己的領(lǐng)域而不會(huì)受到干擾。業(yè)務(wù)外觀層的代碼框架，在系統(tǒng)分析和設(shè)計(jì)完成后就可以完成，他需要提供的方法，就相當(dāng)于在界面設(shè)計(jì)人員和邏輯設(shè)計(jì)人員之間簽訂了一個(gè)協(xié)議，他雖然沒有實(shí)現(xiàn)任何邏輯，但是，他的引入，能使系統(tǒng)的開發(fā)更加有條理，更加簡(jiǎn)明。套用《設(shè)計(jì)模式》上的一句話，就是，“任何問題，都可以通過引入一個(gè)中間層來得到簡(jiǎn)化”。.層的部署和層間交互對(duì)于一個(gè)多層的應(yīng)用軟件系統(tǒng)來說，尤其是大型的應(yīng)用軟件系統(tǒng)，通常需要把不同的部分部署在不同的邏輯或物理設(shè)備上。特別是一些基于Web的應(yīng)用軟件系統(tǒng)，其部署工作將涉及到Web服務(wù)器、組件服務(wù)器、數(shù)據(jù)庫服務(wù)器等不同的服務(wù)設(shè)備。在進(jìn)行應(yīng)用軟件架構(gòu)的設(shè)計(jì)的時(shí)候，必須考慮各種不同的部署^方^案。已經(jīng)有了很多可以用于遠(yuǎn)程訪問的服務(wù)，如此多的實(shí)現(xiàn)技術(shù)，帶來的很大的靈活性，但同時(shí)也帶來了文題，其中一個(gè)就是，有多少種服務(wù)端技術(shù)，就得有多少種相應(yīng)的客戶端訪問技術(shù)。甚至，在某些分布式應(yīng)用系統(tǒng)中，應(yīng)用邏輯使用不同的技術(shù)開發(fā)，存在于不同的機(jī)器上，有的存在于客戶機(jī)本機(jī)，有的使用.NetRemoting開發(fā)，存在于局域網(wǎng)內(nèi)，有的使用因特網(wǎng)上的WebService，有的時(shí)候，我們希望相同的業(yè)務(wù)邏輯能夠支持不同的客戶端。在這種情況下，我們需要一個(gè)一致的服務(wù)訪問編程模型，以統(tǒng)合不同的服務(wù)訪問模式，簡(jiǎn)化系統(tǒng)的開發(fā)和部署。Websharp中的ServiceLocator提供了這樣一種能力，開發(fā)人員只需要定義服務(wù)訪問接口，就可以使用一致的方式透明的訪問這些服務(wù)，而不用理會(huì)這些服務(wù)之間的不同點(diǎn)。框架會(huì)自動(dòng)生成訪問遠(yuǎn)程服務(wù)需要的代理。使用WSL，你可以使用類似于如下的代碼來訪問遠(yuǎn)程服務(wù)，而不用關(guān)心遠(yuǎn)程服務(wù)的種類：publicinterfaceISecuritySystem(boolLogin(stringuserID,stringpassword);voidLogout();