Part 1 層 　　
　　層（layer）這個(gè)概念在計(jì)算機(jī)領(lǐng)域是非常了不得的一個(gè)概念。計(jì)算機(jī)本身就體現(xiàn)了一種層的概念：系統(tǒng)調(diào)用層、設(shè)備驅(qū)動(dòng)層、操作系統(tǒng)層、CPU指令集。每個(gè)層都負(fù)責(zé)自己的職責(zé)。網(wǎng)絡(luò)同樣也是層的概念，最著名的OSI的七層協(xié)議。
　　
　　層到了軟件領(lǐng)域也一樣好用。為什么呢？我們看看使用層技術(shù)有什么好處：
　　
　　● 你使用層，但是不需要去了解層的實(shí)現(xiàn)細(xì)節(jié)。
　　● 可以使用另一種技術(shù)來(lái)改變基礎(chǔ)的層，而不會(huì)影響上面的層的應(yīng)用。
　　● 可以減少不同層之間的依賴(lài)。
　　● 容易制定出層標(biāo)準(zhǔn)。
　　● 底下的層可以用來(lái)建立頂上的層的多項(xiàng)服務(wù)。 當(dāng)然，層也有弱點(diǎn)：
　　● 層不可能封裝所有的功能，一旦有功能變動(dòng)，勢(shì)必要波及所有的層。
　　● 效率降低。
　　
　　當(dāng)然，層最難的一個(gè)問(wèn)題還是各個(gè)層都有些什么，以及要承擔(dān)何種責(zé)任。
　　
　　典型的三層結(jié)構(gòu)
　　
　　三層結(jié)構(gòu)估計(jì)大家都很熟悉了。就是表示（presentation）層, 領(lǐng)域（domain）層, 以及基礎(chǔ)架構(gòu)（infrastructure）層。
　　
　　表示層邏輯主要處理用戶(hù)和軟件的交互。現(xiàn)在最流行的莫過(guò)于視窗圖形界面（wimp）和基于html的界面了。表示層的主要職責(zé)就是為用戶(hù)提供信息，以及把用戶(hù)的指令翻譯。傳送給業(yè)務(wù)層和基礎(chǔ)架構(gòu)層。 基礎(chǔ)架構(gòu)層邏輯包括處理和其他系統(tǒng)的通信，代表系統(tǒng)執(zhí)行任務(wù)。例如數(shù)據(jù)庫(kù)系統(tǒng)交互，和其他應(yīng)用系統(tǒng)的交互等。大多數(shù)的信息系統(tǒng)，這個(gè)層的最大的邏輯就是存儲(chǔ)持久數(shù)據(jù)。
　　
　　還有一個(gè)就是領(lǐng)域?qū)舆壿嫞袝r(shí)也被叫做業(yè)務(wù)邏輯。它包括輸入和存儲(chǔ)數(shù)據(jù)的計(jì)算。驗(yàn)證表示層來(lái)的數(shù)據(jù)，根據(jù)表示層的指令指派一個(gè)基礎(chǔ)架構(gòu)層邏輯。
　　
　　領(lǐng)域邏輯中，人們總是搞不清楚什么事領(lǐng)域邏輯，什么是其它邏輯。例如，一個(gè)銷(xiāo)售系統(tǒng)中有這樣一個(gè)邏輯：如果本月銷(xiāo)售量比上個(gè)月增長(zhǎng)10％，就要用紅色標(biāo)記。要實(shí)現(xiàn)這個(gè)功能，你可能會(huì)把邏輯放在表示層中，比較兩個(gè)月的數(shù)字，如果超出10％，就標(biāo)記為紅色。
　　
　　這樣做，你就把領(lǐng)域邏輯放到了表示層中了。要分離這兩個(gè)層，你應(yīng)該現(xiàn)在領(lǐng)域?qū)又刑峁┮粋€(gè)方法，用來(lái)比較銷(xiāo)售數(shù)字的增長(zhǎng)。這個(gè)方法比較兩個(gè)月的數(shù)字，并返回boolean類(lèi)型。表示層則簡(jiǎn)單的調(diào)用該方法，如果返回true，則標(biāo)記為紅色。
　　
　　例子
　　
　　層技術(shù)不存在說(shuō)永恒的技巧。如何使用都要看具體的情況才能夠決定，下面我就列出了三個(gè)例子：
　　
　　例子1：一個(gè)電子商務(wù)系統(tǒng)。要求能夠同時(shí)處理大量用戶(hù)的請(qǐng)求，用戶(hù)的范圍遍及全球，而且數(shù)字還在不斷增長(zhǎng)。但是領(lǐng)域邏輯很簡(jiǎn)單，無(wú)非是訂單的處理，以 及和庫(kù)存系統(tǒng)的連接部分。這就要求我們1、表示層要友好，能夠適應(yīng)最廣泛的用戶(hù)，因此采用html技術(shù)；2、支持分布式的處理，以勝任同時(shí)幾千的訪問(wèn)； 3、考慮未來(lái)的升級(jí)。
　　
　　例子2：一個(gè)租借系統(tǒng)。系統(tǒng)的用戶(hù)少的多，但是領(lǐng)域邏輯很復(fù)雜。這就要求我們制作一個(gè)領(lǐng)域邏輯非常復(fù)雜的系統(tǒng)，另外，還要給他們的用戶(hù)提供一個(gè)方便的輸入界面。這樣，wimp是一個(gè)不錯(cuò)的選擇。
　　
　　例子3：簡(jiǎn)單的系統(tǒng)。非常簡(jiǎn)單，用戶(hù)少、邏輯少。但是也不是沒(méi)有問(wèn)題，簡(jiǎn)單意味著要快速交付，并且還要充分考慮日后的升級(jí)。因?yàn)樾枨笤诓粩嗟脑黾又小?
　　
　　何時(shí)分層
　　
　　這樣的三個(gè)例子，就要求我們不能夠一概而論的解決問(wèn)題，而是應(yīng)該針對(duì)問(wèn)題的具體情況制定具體的解決方法。這三個(gè)例子比較典型。
　　
　　第二個(gè)例子中，可能需要嚴(yán)格的分成三個(gè)層次，而且可能還要加上另外的中介（mediating）層。例3則不需要，如果你要做的僅是查看數(shù)據(jù)，那僅需要幾個(gè)server頁(yè)面來(lái)放置所有的邏輯就可以了。
　　
　　我一般會(huì)把表示層和領(lǐng)域?qū)?基礎(chǔ)架構(gòu)層分開(kāi)。除非領(lǐng)域?qū)?基礎(chǔ)架構(gòu)層非常的簡(jiǎn)單，而我又可以使用工具來(lái)輕易的綁定這些層。這種兩層架構(gòu)的最好的例子就 是在VB、PB的環(huán)境中，很容易就可以構(gòu)建出一個(gè)基于SQL數(shù)據(jù)庫(kù)的windows界面的系統(tǒng)。這樣的表示層和基礎(chǔ)架構(gòu)層非常的一致，但是一旦驗(yàn)證和計(jì)算 變得復(fù)雜起來(lái)，這種方式就存在先天缺陷了。
　　
　　很多時(shí)候，領(lǐng)域?qū)雍突A(chǔ)架構(gòu)層看起來(lái)非常類(lèi)似，這時(shí)候，其實(shí)是可以把它們放在一起的。可是，當(dāng)領(lǐng)域?qū)拥臉I(yè)務(wù)邏輯和基礎(chǔ)架構(gòu)層的組織方式開(kāi)始不同的時(shí)候，你就需要分開(kāi)二者。
　　
　　更多的層模式
　　
　　三層的架構(gòu)是最為通用的，尤其是對(duì)IS系統(tǒng)。其它的架構(gòu)也有，但是并不適用于任何情況。
　　
　　第一種是Brown model [Brown et al]。它有五個(gè)層：表示層（Presentation），控制/中介層（Controller/Mediator），領(lǐng)域?qū)樱―omain）, 數(shù)據(jù)映射層（Data Mapping）, 和數(shù)據(jù)源層（Data Source）。它其實(shí)就是在三層架構(gòu)種增加了兩個(gè)中間層。控制/中介層位于表示層和領(lǐng)域?qū)又g，數(shù)據(jù)映射層位于領(lǐng)域?qū)雍突A(chǔ)架構(gòu)層之間。
　　
　　表示層和領(lǐng)域?qū)拥闹薪閷樱覀兺ǔ７Q(chēng)之為表示-領(lǐng)域中介層，是一個(gè)常用的分層方法，通常針對(duì)一些非可視的控件。例如為特定的表示層組織信息格式，在不 同的窗口間導(dǎo)航，處理交易邊界，提供Server的facade接口（具體實(shí)現(xiàn)原理見(jiàn)設(shè)計(jì)模式）。最大的危險(xiǎn)就是，一些領(lǐng)域邏輯被放到這個(gè)層里，影響到其 它的表示層。
　　
　　我常常發(fā)現(xiàn)把行為分配給表示層是有好處的。這可以簡(jiǎn)化問(wèn)題。但表示層模型會(huì)比較復(fù)雜，所以，把這些行為放到非可視化的對(duì)象中，并提取出一個(gè)表示-領(lǐng)域中介層還是值得的。
　　
　　Brown ISA
　　表示層 表示層
　　控制/中介層 表示-領(lǐng)域中介層
　　領(lǐng)域?qū)?領(lǐng)域?qū)?
　　數(shù)據(jù)映射層 數(shù)據(jù)庫(kù)交互模式中的Database Mapper
　　數(shù)據(jù)源層 基礎(chǔ)架構(gòu)層
　　
　　領(lǐng)域?qū)雍突A(chǔ)架構(gòu)層之間的中介層屬于本書(shū)中提到的Database Mapper模式，是三種領(lǐng)域?qū)拥綌?shù)據(jù)連接的辦法之一。和表示-領(lǐng)域中介層一眼，有時(shí)候有用，但不是所有時(shí)候都有用。
　　
　　還有一個(gè)好的分層架構(gòu)是J2EE的架構(gòu)，這方面的討論可以見(jiàn)『J2EE核心模式』一書(shū)。他的分層是客戶(hù)層（Client），表示層（Presentation），業(yè)務(wù)層（Business ），整合層（Integration），資源層（Resource）。差別如下圖：
　　
　　J2EE核心 ISA
　　客戶(hù)層 運(yùn)行在客戶(hù)機(jī)上的表示層
　　表示層 運(yùn)行在服務(wù)器上的表示層
　　業(yè)務(wù)層 領(lǐng)域?qū)?
　　整合層 基礎(chǔ)架構(gòu)層
　　資源層 基礎(chǔ)架構(gòu)層通信的外部數(shù)據(jù)
　　
　　微軟的DNA架構(gòu)定義了三個(gè)層：表示層（presentation），業(yè)務(wù)層（business），和數(shù)據(jù)存儲(chǔ)層（data access），這和我的架構(gòu)相似，但是在數(shù)據(jù)的傳遞方式上還有很大的不同。在微軟的DNA中，各層的操作都基于數(shù)據(jù)存儲(chǔ)層傳出的SQL查詢(xún)結(jié)果集。這樣的話，實(shí)際上是增加了表示層和業(yè)務(wù)層同數(shù)據(jù)存儲(chǔ)層之間的耦合度。 DNA的記錄集在層之間的動(dòng)作類(lèi)似于Data Transfer Object。轉(zhuǎn)貼于 265考試網(wǎng) 

Part 2 組織領(lǐng)域邏輯
　　
　　要組織基于層的系統(tǒng)，首要的是如何組織領(lǐng)域邏輯。領(lǐng)域邏輯的組織有好幾種模式。但其中最重要的莫過(guò)于兩種方法：Transation Script和Domain Model。選定了其中的一種，其它的都容易決定。不過(guò)，這兩者之間并沒(méi)有一條明顯的分界線。所以如何選取也是門(mén)大學(xué)問(wèn)。一般來(lái)說(shuō)，我們認(rèn)為領(lǐng)域邏輯比較復(fù)雜的系統(tǒng)可以采用Domain Model。
　　
　　Transation Script就是對(duì)表示層用戶(hù)輸入的處理程序。包括驗(yàn)證和計(jì)算，存儲(chǔ)，調(diào)用其它系統(tǒng)的操作，把數(shù)據(jù)回傳給表示層。用戶(hù)的一個(gè)動(dòng)作表示一個(gè)程序，這個(gè)程序可 以是script，也可以是transation，也可以是幾個(gè)子程序。在例子1中，檢驗(yàn)，在購(gòu)物車(chē)中增加一本書(shū)，顯示遞送狀態(tài)，都可以是一個(gè) Transation Script。
　　
　　Domain Model是要建立對(duì)應(yīng)領(lǐng)域名詞的模型，例如例1中的書(shū)、購(gòu)物車(chē)等。檢驗(yàn)、計(jì)算等處理都放到領(lǐng)域模型中。
　　
　　Transation Script屬于結(jié)構(gòu)性思維，Domain Model屬于OO思維。Domain Model比較難使用，一旦習(xí)慣，你能夠組織更復(fù)雜的邏輯，你的思想會(huì)更OO。到時(shí)候，即使是小的系統(tǒng)，你也會(huì)自然的使用Domain Model了。
　　
　　但如何抉擇呢？如果邏輯復(fù)雜，那肯定用Domain Model：如果只需要存取數(shù)據(jù)庫(kù)，那Transation Script會(huì)好一些。但是需求是在不斷進(jìn)化的，你很難保證以后的需求還會(huì)如此簡(jiǎn)單。如果你的團(tuán)隊(duì)不善于使用Domain Model，那你需要權(quán)衡一下投入產(chǎn)出比。另外，即使是Transation Script，也可以做到把邏輯和基礎(chǔ)架構(gòu)分開(kāi)，你可以使用Gateway。
　　
　　對(duì)例2，毫無(wú)疑問(wèn)要使用Domain Model。對(duì)例1就需要權(quán)衡了。而對(duì)于例3，你很難說(shuō)它將來(lái)會(huì)不會(huì)像例2那樣，你現(xiàn)在可以使用Transation Script，但未來(lái)你可能要使用Domain Model。所以說(shuō)，架構(gòu)的決策是至關(guān)緊要的。
　　
　　除了這兩種模式，還有其它中庸的模式。Use Case Controller就是處于兩者之間。只有和單個(gè)的用例相關(guān)的業(yè)務(wù)邏輯才放到對(duì)象中。所以大致上他們還是在使用Transation Script，而Domain Model只是Database Gateway的一組集合而已。我不太用這種模式。
　　
　　Table Module是另一個(gè)中庸模式。很多的GUI環(huán)境依托于SQL查詢(xún)的返回結(jié)果。你可以建立內(nèi)存中的對(duì)象，來(lái)把GUI和數(shù)據(jù)庫(kù)分開(kāi)來(lái)。為每個(gè)表寫(xiě)一個(gè)模塊，因此每一行都需要關(guān)鍵字變量來(lái)識(shí)別每一個(gè)實(shí)例。
　　
　　Table Module適用于很多的組件構(gòu)建于一個(gè)通用關(guān)系型數(shù)據(jù)庫(kù)之上，而且領(lǐng)域邏輯不太復(fù)雜的情況。Microsoft COM 環(huán)境，以及它的帶ADO.NET的.NET環(huán)境都適合使用這種模式。而對(duì)于Java，就不太適用了。
　　
　　領(lǐng)域邏輯的一個(gè)問(wèn)題是領(lǐng)域?qū)ο蠓浅５挠纺[。因?yàn)閷?duì)象的行為太多了，類(lèi)也就太大了。它必須是一個(gè)超集。這就要考慮哪些行為是通用的，哪些不是，可以由其它的類(lèi)來(lái)處理，可能是Use Case Controller，也可能是表示層。
　　
　　還有一個(gè)問(wèn)題，復(fù)制。他會(huì)導(dǎo)致復(fù)雜和不一致。這比臃腫的危害更大。所以，寧可臃腫，也不要復(fù)制。等到臃腫為害時(shí)再處理它吧。
　　
　　選擇一個(gè)地方運(yùn)行領(lǐng)域邏輯
　　
　　我們的精力集中在邏輯層上。領(lǐng)域邏輯要么運(yùn)行在Client上，要么運(yùn)行在Server上。
　　
　　比較簡(jiǎn)單的做法是全部集中在Server上。這樣你需要使用html的前端以及web server。這樣做的好處是升級(jí)和維護(hù)都非常的簡(jiǎn)單，你也不用考慮桌面平臺(tái)和Server的同步問(wèn)題，也不用考慮桌面平臺(tái)的其它軟件的兼容問(wèn)題。
　　
　　運(yùn)行在Client適合于要求快速反應(yīng)和沒(méi)有聯(lián)網(wǎng)的情況。在Server端的邏輯，用戶(hù)的一個(gè)再小的請(qǐng)求，也需要信息從Client到Server繞一圈。反應(yīng)的速度必然慢。再說(shuō)，網(wǎng)絡(luò)的覆蓋程度也不是說(shuō)達(dá)到了100％。
　　
　　對(duì)于各個(gè)層來(lái)說(shuō)，又是怎么樣的呢？
　　
　　基礎(chǔ)架構(gòu)層：一般都是在Server啦，不過(guò)有時(shí)候也會(huì)把數(shù)據(jù)復(fù)制到合適的高性能桌面機(jī)，但這是就要考慮同步的問(wèn)題了。
　　
　　表示層在何處運(yùn)行取決于用戶(hù)界面的設(shè)計(jì)。一個(gè)Windows界面只能在Client運(yùn)行。而一個(gè)Web界面就是在Server運(yùn)行。也有特別的例子，在桌面機(jī)上運(yùn)行web server的，例如X Server。但這種情況少的多。
　　
　　在例1中，沒(méi)有更多的選擇了，只能選在Server端。因此你的每一個(gè)bit都會(huì)繞一個(gè)大圈子。為了提高效率，盡量使用一些純html腳本。
　　
　　人們選用Windows界面的原因主要就是需要執(zhí)行一些非常復(fù)雜的任務(wù)，需要一個(gè)合適的應(yīng)用程序，而web GUI則無(wú)法勝任。這就是例2的做法。不過(guò)，人們應(yīng)該會(huì)漸漸適應(yīng)web GUI，而web GUI的功能也會(huì)越來(lái)越強(qiáng)大。
　　
　　剩下的是領(lǐng)域邏輯。你可以全部放在Server，也可以全部放在Client，或是兩邊都放。
　　
　　如果是在Client端，你可以考慮全部邏輯都放在Client端，這樣至少保證所有的邏輯都在一個(gè)地方。而把web server移至Client，是可以解決沒(méi)有聯(lián)網(wǎng)的問(wèn)題，但對(duì)反應(yīng)時(shí)間不會(huì)有多大的幫助。你還是可以把邏輯和表示層分離開(kāi)來(lái)。當(dāng)然，你需要額外的升級(jí)和維護(hù)的工作。
　　
　　在Client和Server端都具有邏輯并不是一個(gè)好的處理辦法。但是對(duì)于那些僅有一些領(lǐng)域邏輯的情況是適用的。有一個(gè)小竅門(mén)，把那些和系統(tǒng)的其它部分沒(méi)有聯(lián)系的邏輯封裝起來(lái)。 領(lǐng)域邏輯的接口
　　
　　你的Server上有一些領(lǐng)域邏輯，要和Client通信，你應(yīng)該有什么樣的接口呢？要么是一個(gè)http接口，要么是一個(gè)OO接口。
　　
　　http接口適用于web browser，就是說(shuō)你要選擇一個(gè)html的表示層。最近的新技術(shù)就是web service，通過(guò)基于http、特別是XML進(jìn)行通信。XML有幾個(gè)好處：通信量大，結(jié)構(gòu)好，僅需一次的回路。這樣遠(yuǎn)程調(diào)用的的開(kāi)銷(xiāo)就小了。同時(shí)，XML還是一個(gè)標(biāo)準(zhǔn)，支持平臺(tái)異構(gòu)。XML又是基于文本的，能夠通過(guò)防火墻。
　　
　　雖然XML有那么多的好處，不過(guò)一個(gè)OO的接口還是有它的價(jià)值的。hhtp的接口不明顯，不容易看清楚數(shù)據(jù)是如何處理的。而OO的接口的方法帶有變量和名字，容易看出處理的過(guò)程。當(dāng)然，它無(wú)法通過(guò)防火墻，但可以提供安全和事務(wù)之類(lèi)的控制。
　　
　　最好的還是取二者所長(zhǎng)。OO接口在下，http接口在上。但這樣做就會(huì)使得實(shí)現(xiàn)機(jī)制非常的復(fù)雜。
　　
　　Part 3 組織web Server
　　
　　很多使用html方式的人，并不能真正理解這種方式的優(yōu)點(diǎn)。我們有各種各樣好用的工具，但是卻搞到讓程序難以維護(hù)。
　　
　　在web server上組織程序的方式大致可以分為兩種：腳本和server page。
　　
　　腳本方式就是一個(gè)程序，用函數(shù)和方法來(lái)處理http調(diào)用。例如CGI腳本和java servlet。它和普通的程序并沒(méi)有什么兩樣。它從web頁(yè)面上獲得html string形態(tài)的數(shù)據(jù)，有時(shí)候還要做一些表達(dá)式匹配，這正是perl能夠成為CGI腳本的常用語(yǔ)言的原因。而java servelet則是把這種分析留給程序員，但它允許程序員通過(guò)關(guān)鍵字接口來(lái)訪問(wèn)信息，這樣就會(huì)少一些表達(dá)式的判斷。這種格式的web server輸出是另一種html string，稱(chēng)為response，可以通過(guò)流數(shù)據(jù)來(lái)操作。
　　
　　糟糕的是流數(shù)據(jù)是非常麻煩的，因此就導(dǎo)致了server page的產(chǎn)生，例如PHP，ASP，JSP。
　　
　　server page的方式適合回應(yīng)（response）的處理比較簡(jiǎn)單的情況。例如“顯示歌曲的明細(xì)”，但是你的決策取決于輸入的時(shí)候，就會(huì)比較雜亂。例如“通俗和搖滾的顯示格式不同”。
　　
　　腳步擅長(zhǎng)于處理用戶(hù)交互，server page擅長(zhǎng)于處理格式化回應(yīng)信息。所以很自然的就會(huì)采用腳本處理請(qǐng)求的交互，使用server page處理回應(yīng)的格式化。這其實(shí)就是著名的MVC（Model View Controller）模式中的view/controller的處理。
　　
　　應(yīng)用Model View Controller模式首要的一點(diǎn)就是模型要和web服務(wù)完全分離開(kāi)來(lái)。使用Transaction Script或Domain Model模式來(lái)封裝處理流程。
　　
　　接下來(lái)，我們就把剩余的模式歸入兩類(lèi)模式中：屬于Controller的模式，以及屬于View的模式。
　　
　　View模式
　　
　　View這邊有三種模式：Transform View，Template View和Two Step View。Transform View和Template View的處理只有一步，將領(lǐng)域數(shù)據(jù)轉(zhuǎn)換為html。Two Step View要經(jīng)過(guò)兩步的處理，第一步把領(lǐng)域數(shù)據(jù)轉(zhuǎn)換為邏輯表示形式，第二步把邏輯表示轉(zhuǎn)換為html。
　　
　　兩步處理的好處是可以將邏輯集中于一處，如果只有一步，變化發(fā)生時(shí)，你就需要修改每一個(gè)屏幕。但這需要你有一個(gè)很好的邏輯屏幕結(jié)構(gòu)。如果一個(gè)web應(yīng)用有很多的前端用戶(hù)時(shí)，兩步處理就特別的好用。例如航空訂票系統(tǒng)。使用不同的第二步處理，就可以獲得不同的邏輯屏幕。
　　
　　使用單步方法有兩個(gè)可選的模式：Template View，Transform View。Template View其時(shí)就是把代碼嵌入到html頁(yè)面中，就像現(xiàn)在的server page技術(shù)，如ASP，PHP，JSP。這種模式靈活，強(qiáng)大，但顯得雜亂無(wú)章。如果你能夠把邏輯程序邏輯在頁(yè)面結(jié)構(gòu)之外進(jìn)行很好的組織，這種模式還是有它的優(yōu)點(diǎn)的。
　　
　　Transform View使用翻譯方式。例如XSLT。如果你的領(lǐng)域數(shù)據(jù)是用XML處理的，那這種模式就特別的好用。
　　
　　Controller模式
　　
　　Controller有兩種模式。一般我們會(huì)根據(jù)動(dòng)作來(lái)決定一項(xiàng)控制。動(dòng)作可能是一個(gè)按鈕或鏈接。所這種模式就是Action Controller模式。
　　
　　Front Controller更進(jìn)一步，它把http請(qǐng)求的處理和處理邏輯分離開(kāi)來(lái)。一般是只有一個(gè)web handle來(lái)處理所有的請(qǐng)求。你的所有的http請(qǐng)求的處理都由一個(gè)對(duì)象來(lái)負(fù)責(zé)。你改變動(dòng)作結(jié)構(gòu)的影響就會(huì)降到最小。