本文來(lái)源不詳！
何時(shí)使用分層技術(shù)？
分層技術(shù)實(shí)際上是把技術(shù)復(fù)雜化了。和以往簡(jiǎn)單的CS結(jié)構(gòu)的系統(tǒng)不同，分層往往需要使用特定的技術(shù)平臺(tái)來(lái)實(shí)現(xiàn)。當(dāng)然，不使用這些技術(shù)平臺(tái)也是可能的，但是效果可能就沒(méi)有那么好了。支持分層技術(shù)的平臺(tái)有很多，包括目前主流的J2EE和.NET。甚至在不同廠商的開(kāi)發(fā)平臺(tái)上，要求也不一樣。使用分層技術(shù)實(shí)現(xiàn)的多層架構(gòu)，成本要比普通的CS架構(gòu)高得多。
這就產(chǎn)生了一個(gè)非?，F(xiàn)實(shí)的問(wèn)題－并不是所有的軟件都適合采用分層技術(shù)的。一般來(lái)說(shuō)，小型的軟件使用分層并沒(méi)有太大的意義，因?yàn)榉謱訉?dǎo)致的成本超過(guò)它所能帶來(lái)的好處。在一般的CS結(jié)構(gòu)中，可以把界面控制、邏輯處理和數(shù)據(jù)庫(kù)訪問(wèn)都放在一塊兒。這種設(shè)計(jì)方式在純粹的多層主義者看來(lái)簡(jiǎn)直就是十惡不赦。但是對(duì)于小型的軟件而言，這并不是什么大不了的事情。因?yàn)閺谋硎緦拥綌?shù)據(jù)層的整套功能都被囊括在一個(gè)功能塊中，同樣能夠?qū)崿F(xiàn)較好的封裝。而且，如果結(jié)構(gòu)設(shè)計(jì)的足夠好，也能夠避免表示層、業(yè)務(wù)層和數(shù)據(jù)層之間出現(xiàn)過(guò)高的耦合度。因此，除非確實(shí)需要，不然沒(méi)有必要使用分層技術(shù)。
尤其在處理一些特殊的項(xiàng)目時(shí)，嚴(yán)格的區(qū)分三層結(jié)構(gòu)并不理想。比如在快速開(kāi)發(fā)windows界面的應(yīng)用時(shí)，往往會(huì)用到一些對(duì)數(shù)據(jù)庫(kù)敏感的控件，這種處理方法跨越了三個(gè)層次，但是卻很實(shí)用，成本也比較低。又比如一些框架，給出了從界面層到數(shù)據(jù)庫(kù)的綜合的解決方案，和windows的應(yīng)用類似，嚴(yán)格的三層技術(shù)也不適用于這種情況。
如何使用分層技術(shù)？
從某種意義上來(lái)看，層其實(shí)是一個(gè)粗粒度的組件。就像我們使用組件技術(shù)是為了對(duì)系統(tǒng)進(jìn)行一種劃分一樣，層的一個(gè)很大的作用也是如此。其目的是為了系統(tǒng)更容易被理解，不同的部分能夠被較容易的替換。
使用分層技術(shù)的依據(jù)是軟件開(kāi)發(fā)人員的實(shí)際需要。如果你是在使用某些優(yōu)秀的面向?qū)ο蟮能浖_(kāi)發(fā)平臺(tái)的話，那它們一般都會(huì)建議（或是強(qiáng)制）你使用某一種分層機(jī)制。這是你采用分層技術(shù)的一大參考。
對(duì)于大多數(shù)有一定經(jīng)驗(yàn)的軟件團(tuán)隊(duì)而言，一般都會(huì)積累一些軟件開(kāi)發(fā)經(jīng)驗(yàn)。其中包含了很多在某些特定的領(lǐng)域中使用的基礎(chǔ)的類或組件。這些元素構(gòu)成了一個(gè)系統(tǒng)的通用層次。這個(gè)層次也是分層時(shí)需要考慮的。例如一些應(yīng)用軟件中使用的一些通用的Currency對(duì)象或是Organization對(duì)象。分析模式一書對(duì)此類的對(duì)象進(jìn)行了充分細(xì)致的闡述。這個(gè)層次一般被稱為跨領(lǐng)域?qū)樱╟ross-domain layer），或稱為工具層（utility layer）。
目前的很多軟件都采用了數(shù)據(jù)庫(kù)映射技術(shù)。數(shù)據(jù)庫(kù)映射層對(duì)于企業(yè)應(yīng)用系統(tǒng)非常的重要，因此也需要納入考慮之列。數(shù)據(jù)庫(kù)映射技術(shù)用起來(lái)簡(jiǎn)單，但是要實(shí)現(xiàn)可不容易。如果不是非常有必要，盡可能使用現(xiàn)成的框架，或是采用其中部分的設(shè)計(jì)思路。試圖構(gòu)建一個(gè)大而全的映射層次的代價(jià)是非常高昂的，認(rèn)識(shí)不到這一點(diǎn)會(huì)帶來(lái)很大的麻煩。數(shù)據(jù)庫(kù)映射技術(shù)的知識(shí)，我們?cè)谙挛闹羞€有專門的篇幅來(lái)討論。
如何存放數(shù)據(jù)（狀態(tài)）？
在學(xué)習(xí)EJB的過(guò)程中，最先要理解的一定是有狀態(tài)和無(wú)狀態(tài)的概念。可以說(shuō)，整個(gè)概念是多層體系的核心。為什么這么說(shuō)呢？這里的狀態(tài)指的是類的狀態(tài)，例如類的屬性、變量等。由于狀態(tài)的不同，類也表現(xiàn)出差異來(lái)。而對(duì)于多層結(jié)構(gòu)的軟件，創(chuàng)建和銷毀一個(gè)類的開(kāi)銷是很大的，如果該軟件支持分布式的話尤為如此。所以如果系統(tǒng)的不同層次間進(jìn)行頻繁的調(diào)用－創(chuàng)建一個(gè)類，再銷毀一個(gè)類。這種做法是非常消耗資源的。在應(yīng)用系統(tǒng)的設(shè)計(jì)中，一般不單獨(dú)使用COM，就是這個(gè)原因。所以我們很自然的想到了一種經(jīng)典的設(shè)計(jì)－緩沖池。把對(duì)象存放在緩沖池中，當(dāng)需要的時(shí)候從池中取出一個(gè)，當(dāng)不需要的時(shí)候再把對(duì)象放入池中。這種設(shè)計(jì)思路能夠大幅度的提高效率。但是這對(duì)能夠放在池中的對(duì)象也提出了苛刻的要求－所有的對(duì)象必須是無(wú)差異的，也就是無(wú)狀態(tài)的。只有這樣才能夠?qū)崿F(xiàn)緩沖池。
一般來(lái)說(shuō)，對(duì)象緩沖池的技術(shù)是用在中間的業(yè)務(wù)層上的。既然中間業(yè)務(wù)層上不能夠保留有狀態(tài)，那就出現(xiàn)了一個(gè)狀態(tài)轉(zhuǎn)移的問(wèn)題。這里有兩種的選擇，一種是前移，把狀態(tài)移到用戶端，最典型的是使用cookie。這種選擇一般是由于狀態(tài)和用戶端有關(guān)，不需要長(zhǎng)時(shí)間保存。另一種選擇是后移，把狀態(tài)移到數(shù)據(jù)層，由數(shù)據(jù)庫(kù)來(lái)實(shí)現(xiàn)持久性狀態(tài)，當(dāng)需要時(shí)才把狀態(tài)提交給業(yè)務(wù)層。這種方式是企業(yè)應(yīng)用軟件中采用最多的，但是也增大了數(shù)據(jù)庫(kù)的負(fù)擔(dān)。
處理好接口
由于使用了分層技術(shù)，因此原先那種在CS結(jié)構(gòu)中類之間存在復(fù)雜關(guān)系就有必要重新評(píng)估了。一般層間的耦合度不宜過(guò)大。因此需要慎重的設(shè)計(jì)層之間的類調(diào)用方式。一些分布式軟件體系（例如J2EE）對(duì)層之間的調(diào)用方式以接口的形式給出了要求。同時(shí)，不同層之間僅僅知道目標(biāo)層的接口，而不知道目標(biāo)層的具體實(shí)現(xiàn)。EJB的home接口和remote接口就是這樣。在COM+體系中，也需要在設(shè)計(jì)類的同時(shí)，把接口公布出來(lái)，以供客戶方使用。
在設(shè)計(jì)層間的接口時(shí)，除了考慮開(kāi)發(fā)平臺(tái)的約束之外，還有一點(diǎn)是開(kāi)發(fā)人員必須考慮的。那就是業(yè)務(wù)需要。業(yè)務(wù)層中往往有非常多的對(duì)象和方法，它們之間的關(guān)系也非常的負(fù)責(zé)，但對(duì)于其它的層次來(lái)說(shuō)，它并不關(guān)心這些細(xì)節(jié)。因此業(yè)務(wù)層公布的接口必須要簡(jiǎn)單，而且和實(shí)現(xiàn)無(wú)關(guān)。因此，可以使用設(shè)計(jì)模式的Facade模式來(lái)簡(jiǎn)化層間的接口。這種做法非常有效，EJB中的SessionBean和EntityBean區(qū)分就含有這種設(shè)計(jì)思路。
同樣的，不同層之間的數(shù)據(jù)傳遞也存在問(wèn)題。如果不同層的物理節(jié)點(diǎn)在一起還好辦，如果不在一起，那就需要使用到分布式技術(shù)了。因?yàn)椴煌瑱C(jī)器的內(nèi)存地址編碼是不同的，如果接口之間采用對(duì)象引用的方式，那一定會(huì)出現(xiàn)問(wèn)題。因此會(huì)將對(duì)象打包成字符串，發(fā)送到目標(biāo)機(jī)器后再還原為對(duì)象。所有的分布式平臺(tái)都提供了對(duì)這種技術(shù)的支持，這里就不多說(shuō)了。但是這種實(shí)現(xiàn)技術(shù)會(huì)對(duì)我們的設(shè)計(jì)思路產(chǎn)生影響，少量的數(shù)據(jù)直接使用字符串來(lái)傳遞，數(shù)據(jù)量大的話，就需要使用封裝了數(shù)據(jù)的對(duì)象。這類對(duì)象的設(shè)計(jì)需要非常的小心。在設(shè)計(jì)過(guò)程中可以參照開(kāi)發(fā)平臺(tái)提供的一些標(biāo)準(zhǔn)做法。同樣的，數(shù)據(jù)的請(qǐng)求的頻率也是難點(diǎn)之一。過(guò)于頻繁的操作來(lái)自后端的數(shù)據(jù)會(huì)加大系統(tǒng)的開(kāi)銷。因此，在設(shè)計(jì)調(diào)用方法時(shí)同樣需要結(jié)合實(shí)際應(yīng)用來(lái)考慮。
兼顧效率
一般來(lái)說(shuō)，純粹的面向?qū)ο笤O(shè)計(jì)者設(shè)計(jì)出的軟件都會(huì)比較完美。但是需要付出一定的代價(jià)。在一些大的軟件平臺(tái)上編程的時(shí)候，往往需要利用到平臺(tái)的一些機(jī)制。最典型的就是平臺(tái)的事務(wù)機(jī)制（最典型的包括J2EE平臺(tái)的JTS，以及COM+平臺(tái)的MTS），但是事務(wù)機(jī)制的實(shí)現(xiàn)往往需要平臺(tái)大量對(duì)象的支撐。這種情況下，創(chuàng)建一個(gè)支持事務(wù)的對(duì)象的開(kāi)銷是很大的。處理這種問(wèn)題有一種變通的辦法，就是僅僅對(duì)需要事務(wù)支撐的對(duì)象提供事務(wù)支持。這就意味著，一個(gè)單獨(dú)的業(yè)務(wù)實(shí)體類，可能需要根據(jù)是否支持事務(wù)分為兩種類：對(duì)該業(yè)務(wù)實(shí)體的select方法不需要事務(wù)的支持，只有update和delete方法才需要有事務(wù)的支持。這是不符合純面向?qū)ο笤O(shè)計(jì)者的觀點(diǎn)的。但是這種做法卻可以獲得比較優(yōu)秀的效率。
應(yīng)該承認(rèn)，這種提高效率的做法加大了復(fù)雜度。因?yàn)閷?duì)于客戶端來(lái)說(shuō)，它們并不關(guān)心具體的實(shí)現(xiàn)技術(shù)。要求客戶端在某一種情況下調(diào)用這個(gè)類，在其它情況下又調(diào)用另一個(gè)類，這種做法既不符合面向?qū)ο蟮脑O(shè)計(jì)思路，也增大了層間耦合度及復(fù)雜性。因此，我們可以考慮使用接口或是外觀類（參見(jiàn)設(shè)計(jì)模式一書中的facade模式），把具體的實(shí)現(xiàn)封裝起來(lái)，而只把用戶關(guān)心的部分提供給用戶。這方面的技巧我們?cè)谙旅娴恼鹿?jié)中還會(huì)提到。
以迭代的方式進(jìn)行分層
軟件設(shè)計(jì)中的迭代做法同樣可以適用于分層。根據(jù)自己的經(jīng)驗(yàn)，在一開(kāi)始就定義好所有的層次是很難的。除非有著非常豐富的經(jīng)驗(yàn)，都則實(shí)現(xiàn)和原先的設(shè)計(jì)總有或大或小的差距。因此調(diào)整勢(shì)在必行。每一次的迭代都能夠?qū)Ψ謱蛹夹g(shù)進(jìn)行改進(jìn)，并為后一個(gè)項(xiàng)目積累了經(jīng)驗(yàn)。
這里的分層迭代不可以過(guò)于頻繁，每一次的迭代都是對(duì)架構(gòu)的重大修改，都是需要投入人力的，而且會(huì)影響到軟件開(kāi)發(fā)的進(jìn)度。但是成功的迭代的效果是非常明顯的，能夠在接下來(lái)的開(kāi)發(fā)周期中起到穩(wěn)定架構(gòu)，減少代碼量，提升軟件質(zhì)量的功效。注意，不要讓新潮技術(shù)成為分層迭代的推動(dòng)力。這是開(kāi)發(fā)人員都常犯的毛病，這并不是什么缺點(diǎn)，只能稱為一種職業(yè)病吧。分層迭代的推動(dòng)力應(yīng)該源自于需求的演進(jìn)以及現(xiàn)有架構(gòu)的不穩(wěn)定已經(jīng)妨礙了軟件進(jìn)一步的開(kāi)發(fā)。因此這需要團(tuán)隊(duì)中的技術(shù)主管對(duì)技術(shù)有著非常好的把握。
重構(gòu)能夠?qū)Φ兴鶐椭?。嗅出代碼中隱藏的壞味道并加以改進(jìn)。應(yīng)該說(shuō)，迭代是一種比較激烈的做法，更好的做法是在開(kāi)發(fā)中不斷的對(duì)架構(gòu)、層次進(jìn)行調(diào)整。但這對(duì)團(tuán)隊(duì)、技術(shù)、方法、過(guò)程都有著很高的要求。因此迭代仍然是一種主要的改進(jìn)手段。
層內(nèi)的細(xì)分
分層的思路還可以適用于層的內(nèi)部。層內(nèi)的細(xì)分并沒(méi)有固定的方式，其驅(qū)動(dòng)因素往往是出于封裝性和重用的考慮。例如，在EJB體系中的業(yè)務(wù)層中，實(shí)體Bean負(fù)責(zé)實(shí)現(xiàn)業(yè)務(wù)對(duì)象，因此一個(gè)應(yīng)用往往擁有大量的實(shí)體Bean。而用戶端并不需要了解每一個(gè)的實(shí)體Bean，對(duì)它們來(lái)說(shuō)，只要能夠完全一些業(yè)務(wù)邏輯就可以了，但完成這些業(yè)務(wù)邏輯則需要和多個(gè)實(shí)體Bean打交道。因此EJB提供了會(huì)話Bean，來(lái)負(fù)責(zé)把實(shí)體Bean封裝起來(lái)，用戶只知道會(huì)話Bean，不知道實(shí)體Bean的存在。這樣既保證了實(shí)體Bean的重用性，又很好的實(shí)現(xiàn)了封裝。
面向接口編程
在前面的章節(jié)中，我們提到一個(gè)接口設(shè)計(jì)的例子。為什么我們提倡接口的設(shè)計(jì)呢？Martin Fowler在他的分析模式一書中指出，分析問(wèn)題應(yīng)該站在概念的層次上，而不是站在實(shí)現(xiàn)的層次上。什么叫做概念的層次呢？簡(jiǎn)單的說(shuō)就是分析對(duì)象該做什么，而不是分析對(duì)象怎么做。前者屬于分析的階段，后者屬于設(shè)計(jì)甚至是實(shí)現(xiàn)的階段。在需求工程中有一種稱為CRC卡片的玩藝兒，是用來(lái)分析類的職責(zé)和關(guān)系的，其實(shí)那種方法就是從概念層次上進(jìn)行面向?qū)ο笤O(shè)計(jì)。因此，如果要從概念層次上進(jìn)行分析，這就要求你從領(lǐng)域?qū)＜业慕嵌葋?lái)看待程序是如何表示現(xiàn)實(shí)世界中的概念的。下面的這句話有些拗口，從實(shí)現(xiàn)的角度上來(lái)說(shuō)，概念層次對(duì)應(yīng)于合同，合同的實(shí)現(xiàn)形式包括接口和基類。簡(jiǎn)單的說(shuō)吧，在概念層次上進(jìn)行分析就是設(shè)計(jì)出接口（或是基類），而不用關(guān)心具體的接口實(shí)現(xiàn)（實(shí)現(xiàn)推遲到子類再實(shí)現(xiàn)）。結(jié)合上面的論述，我們也可以這樣推斷，接口應(yīng)該是要符合現(xiàn)實(shí)世界的觀念的。
在Martin Fowler的另一篇著作中提到了這樣一個(gè)例子，非常好的解釋了接口編程的思路：
|
interface Person {
public String name();
public void name(String newName);
public Money salary ();
public void salary (Money newSalary);
public Money payAmount ();
public void makeManager ();
}
interface Engineer extends Person{
public void numberOfPatents (int value);
public int numberOfPatents ();
}
interface Salesman extends Person{
public void numberOfSales (int numberOfSales);
public int numberOfSales ();
}
interface Manager extends Person{
public void budget (Money value);
public Money budget ();
}
|
可以看到，為了表示現(xiàn)實(shí)世界中人（這里其實(shí)指的是員工的概念）、工程師、銷售員、經(jīng)理的概念，代碼根據(jù)人的自然觀點(diǎn)設(shè)計(jì)了繼承層次結(jié)構(gòu)，并很好的實(shí)現(xiàn)了重用。而且，我們可以認(rèn)定該接口是相對(duì)穩(wěn)定的。我們?cè)賮?lái)看看實(shí)現(xiàn)部分：
|
public class PersonImpFlag implements Person, Salesman, Engineer,Manager{
// Implementing Salesman
public static Salesman newSalesman (String name){
PersonImpFlag result;
result = new PersonImpFlag (name);
result.makeSalesman();
return result;
};
public void makeSalesman () {
_jobTitle = 1;
};
public boolean isSalesman () {
return _jobTitle == 1;
};
public void numberOfSales (int value){
requireIsSalesman () ;
_numberOfSales = value;
};
public int numberOfSales () {
requireIsSalesman ();
return _numberOfSales;
};
private void requireIsSalesman () {
if (! isSalesman()) throw new PreconditionViolation ("Not a Salesman") ;
};
private int _numberOfSales;
private int _jobTitle;
}
|
這是其中一種被稱為內(nèi)部標(biāo)示（Internal Flag）的實(shí)現(xiàn)方法。這里我們只是舉出一個(gè)例子，實(shí)際上我們還有非常多的解決方法，但我們并不關(guān)心。因?yàn)橹灰涌谧銐蚍€(wěn)定，內(nèi)部實(shí)現(xiàn)發(fā)生再大的變化都是允許的。如果對(duì)實(shí)現(xiàn)的方式感興趣，可以參考Matrin Fowler的角色建模的文章或是我在閱讀這篇文章的一篇筆記。
通過(guò)上面的例子，我們可以了解到，接口和實(shí)現(xiàn)分離的最大好處就是能夠在客戶端未知的情況下修改實(shí)現(xiàn)代碼。這個(gè)特性對(duì)于分層技術(shù)是非常適用的。一種是用在層和層之間的調(diào)用。層和層之間是最忌諱耦合度過(guò)高或是改變過(guò)于頻繁的。設(shè)計(jì)優(yōu)秀的接口能夠解決這個(gè)問(wèn)題。另一種是用在那些不穩(wěn)定的部分上。如果某些需求的變化性很大，那么定義接口也是一種解決之道。舉個(gè)不恰當(dāng)?shù)睦?，設(shè)計(jì)良好的接口就像是我們?nèi)粘Ｊ褂玫娜f(wàn)用插座一樣，不論插頭如何變化，都可以使用。
最后強(qiáng)調(diào)一點(diǎn)，良好的接口定義一定是來(lái)自于需求的，它絕對(duì)不是程序員絞盡腦汁想出來(lái)的。
數(shù)據(jù)映射層
在各個(gè)層的設(shè)計(jì)中，可能比較令人困惑的就是數(shù)據(jù)映射層了。由于篇幅的關(guān)系，我們不可能在這個(gè)問(wèn)題上討論太多，只能是拋磚引玉。如果有機(jī)會(huì)，我們還可以來(lái)談?wù)勥@方面的話題。
面向?qū)ο蠹夹g(shù)已經(jīng)成為軟件開(kāi)發(fā)的一種趨勢(shì)，越來(lái)越多的人開(kāi)始了解、學(xué)習(xí)和使用面向?qū)ο蠹夹g(shù)。而大多數(shù)的面向?qū)ο蠹夹g(shù)都只是解決了內(nèi)存中的面向?qū)ο蟮膯?wèn)題。但是鮮有提到持久性的面向?qū)ο髥?wèn)題。
面向?qū)ο笤O(shè)計(jì)的機(jī)制與關(guān)系模型有很大的不同，這造成了面向?qū)ο笤O(shè)計(jì)與關(guān)系數(shù)據(jù)庫(kù)設(shè)計(jì)之間的不匹配。面向?qū)ο笤O(shè)計(jì)的基本理論包括耦合、聚合、封裝、繼承、多態(tài)，而關(guān)系數(shù)據(jù)模型的理論則完全不同，它的基本原理是數(shù)據(jù)庫(kù)的三大范式。最明顯的一個(gè)例子是，Order對(duì)象包括一組的OrderItem對(duì)象，因此我們需要在Order類中設(shè)計(jì)一個(gè)容器（各個(gè)編程語(yǔ)言都提供了一組的容器對(duì)象及相關(guān)操作以供使用）來(lái)存儲(chǔ)OrderItem，也就是說(shuō)Order類中的指針指向OrderItem。假設(shè)Order類和OrderItem分別對(duì)應(yīng)于數(shù)據(jù)庫(kù)的兩張表（最簡(jiǎn)單的映射情況），那么，我們要實(shí)現(xiàn)二者之間的關(guān)系，是通過(guò)在OrderItem表（假設(shè)名稱一樣）增加指向Order表的外鍵。這是兩種完全不同的設(shè)置。數(shù)據(jù)映射層的作用就是向用戶端隱藏關(guān)系數(shù)據(jù)庫(kù)的存在。
自己開(kāi)發(fā)一個(gè)對(duì)象/關(guān)系映射工具是非常誘人的。但是應(yīng)該考慮到，開(kāi)發(fā)這樣一個(gè)工具并不是一件容易的事，需要付出很大的成本。尤其是手工處理數(shù)據(jù)一致性和事務(wù)處理的問(wèn)題上。它比你想象的要難的多。因此，獲取一個(gè)對(duì)象/關(guān)系映射工具的最好途徑是購(gòu)買，而不是開(kāi)發(fā)。
總結(jié)
分層對(duì)現(xiàn)代的軟件開(kāi)發(fā)而言是非常重要的概念。也是我們必須學(xué)習(xí)的知識(shí)。分層的總體思路并沒(méi)有什么特別的地方，但是要和自己的開(kāi)發(fā)環(huán)境、應(yīng)用環(huán)境結(jié)合起來(lái)，你還需要付出很多的努力才行。
在完成了分層之后，軟件架構(gòu)其實(shí)已經(jīng)清晰化了。
本博客為學(xué)習(xí)交流用，凡未注明引用的均為本人作品，轉(zhuǎn)載請(qǐng)注明出處，如有版權(quán)問(wèn)題請(qǐng)及時(shí)通知。由于博客時(shí)間倉(cāng)促，錯(cuò)誤之處敬請(qǐng)諒解，有任何意見(jiàn)可給我留言，愿共同學(xué)習(xí)進(jìn)步。