三層簡(jiǎn)介

先說說Web三層架構(gòu)這個(gè)古老話題。地球人都知道web三層架構(gòu)是指:

• >用戶接口層(UI Layer)

• >業(yè)務(wù)邏輯層(Bussiness Layer)

• >持久化層

關(guān)于業(yè)務(wù)邏輯和用戶接口

在早期的web開發(fā)中，因?yàn)闃I(yè)務(wù)比較簡(jiǎn)單，并沒有這三層的劃分。用戶數(shù)據(jù)的呈現(xiàn)及輸入的接收、封裝、驗(yàn)證、處理、以及對(duì)數(shù)據(jù)庫的操作，都放在jsp頁面中。這時(shí)的開發(fā)，好比盤古尚未開天辟地，整個(gè)web開發(fā)就是一片“混沌”。隨著業(yè)務(wù)越來越復(fù)雜，人們開始考慮更好的利用OOP這把利刃來解決問題。于是有人發(fā)現(xiàn)把業(yè)務(wù)邏輯抽取出來并形成與顯示和持久化無關(guān)的一層，能夠讓業(yè)務(wù)邏輯清晰，產(chǎn)品更便于維護(hù)。這就是SUN當(dāng)初倡導(dǎo)的JSP Model 1開發(fā)方式。

關(guān)于持久化

JSP M1開發(fā)方式中，并沒有對(duì)數(shù)據(jù)如何持久化給出建議。在許多公司中，它們的產(chǎn)品是以數(shù)據(jù)庫為中心進(jìn)行架構(gòu)和設(shè)計(jì)的。在他們的產(chǎn)品里，雖然也有DAO層，但是職責(zé)不清。為什么這么說呢，因?yàn)槲野l(fā)現(xiàn)在許多人眼里，DAO層的指責(zé)很簡(jiǎn)單——增刪改查。但我認(rèn)為，這樣理解實(shí)際上是本末倒置了。對(duì)于簡(jiǎn)單數(shù)據(jù)的管理來說，這樣理解無可厚非。但隨著業(yè)務(wù)邏輯變得日益復(fù)雜。我們實(shí)在是被復(fù)雜的對(duì)象關(guān)系搞頭疼了，如果這時(shí)我們還要考慮如何把數(shù)據(jù)存儲(chǔ)起來(通常的情況下是存到關(guān)系型數(shù)據(jù)庫中)，我們開始抱怨自己軟件的架構(gòu)太惡心，一團(tuán)糟。面向?qū)ο笤O(shè)計(jì)思想教會(huì)我們——如果我們不想做這件事，就交給別人做吧！這時(shí)聰明的架構(gòu)師們提出了一個(gè)概念——持久化。如果我們?cè)谧约旱膽?yīng)用中添加一個(gè)新的層——專門負(fù)責(zé)對(duì)象狀態(tài)的持久化保存及同步，那不就可以全心全意的“搞對(duì)象”了嗎？持久化概念的產(chǎn)生，代表著我們對(duì)關(guān)系型數(shù)據(jù)庫的依賴降低了。因此甚至有人推斷——數(shù)據(jù)庫已死。同時(shí)，關(guān)系型數(shù)據(jù)庫這個(gè)新的概念也不斷形成，并演化成理論，又由理論衍生出產(chǎn)品。因此一個(gè)意識(shí)良好的程序員，至少應(yīng)該認(rèn)同，持久化并不是產(chǎn)品中最重要的環(huán)節(jié)——最重要的環(huán)節(jié)是清晰正確的業(yè)務(wù)邏輯。

層架構(gòu)的好處：

1、采用3層邏輯架構(gòu)，有效的將系統(tǒng)劃分為界面處理層，業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層。這樣劃分層的好處是每一層都具有相對(duì)獨(dú)立的職責(zé)，降低了層與層之間的依賴性。即使某一層發(fā)生變化，也不會(huì)影響其他層，從而確保了架構(gòu)的穩(wěn)定性。

2、將界面與邏輯代碼分開，即使頁面發(fā)生變化，對(duì)業(yè)務(wù)邏輯不會(huì)產(chǎn)生影響。因此，客戶端界面使用Win Form 或者M(jìn)obile Web Form時(shí)，只需新建用戶界面層而直接重用業(yè)務(wù)邏輯層提供的服務(wù)即可。

======可是，雖然三層架構(gòu)有諸多好多，有些問題是解決不了的=======

例1：表單數(shù)據(jù)的驗(yàn)證及封裝：

假設(shè)我們正在做一個(gè)簡(jiǎn)單的表單提交，我們希望對(duì)用戶數(shù)據(jù)的數(shù)據(jù)進(jìn)行驗(yàn)證和封裝，最終交給業(yè)務(wù)邏輯層一個(gè)實(shí)體對(duì)象。從三層架構(gòu)分析，我們想要做的事情是這樣的:

但是該把驗(yàn)證和封裝數(shù)據(jù)的工作交給誰來做呢？UI層還是業(yè)務(wù)邏輯層？都不太合適！

例2 如果我們想為不同國家和地區(qū)的人提供不同的語言，無疑需要國際化的支持。那么，我們需要在JSP頁面上根據(jù)用戶的配置或請(qǐng)求信息判斷應(yīng)該為該用戶呈現(xiàn)哪國文字。而這些判斷和顯示的邏輯應(yīng)該劃分到業(yè)務(wù)邏輯層還是UI層呢？

用MVC的思路解決問題

對(duì)于糾纏不清的問題，我們總要想辦法將其分解。MVC是一種設(shè)計(jì)思想。這種思想強(qiáng)調(diào)實(shí)現(xiàn)模型(Model)、視圖(View)和控制器的分離。這種思想是如何作用于web的呢？實(shí)際上，我們?cè)趙eb開發(fā)中引入MVC思想，想要達(dá)到的目的是：實(shí)現(xiàn)UI層和業(yè)務(wù)邏輯層分離——控制器是為了實(shí)現(xiàn)上述目的而存在的！

在解決了持久化的問題后，我們發(fā)現(xiàn)，我們的所說的業(yè)務(wù)邏輯層和MVC中的Model指的是一回事，我們所說的UI層和MVC中的View是一回事。MVC提供了讓模型和視圖相分離的思路——引入控制器。我們把頁面跳轉(zhuǎn)關(guān)系管理、表單數(shù)據(jù)的封裝及驗(yàn)證、國際化等任務(wù)交給控制器處理。因此，也不難理解為什么流行的MVC框架都具有管理頁面跳轉(zhuǎn)關(guān)系、表單數(shù)據(jù)的封裝及驗(yàn)證、國際化等特性。

MVC的好處：

耦合性低

視圖層和業(yè)務(wù)層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個(gè)應(yīng)用的業(yè)務(wù)流程或者業(yè)務(wù)規(guī)則的改變只需要改動(dòng)MVC的模型層即可。因?yàn)槟Ｐ团c控制器和視圖相分離，所以很容易改變應(yīng)用程序的數(shù)據(jù)層和業(yè)務(wù)規(guī)則。

模型是自包含的，并且與控制器和視圖相分離，所以很容易改變應(yīng)用程序的數(shù)據(jù)層和業(yè)務(wù)規(guī)則。如果把數(shù)據(jù)庫從MySQL移植到Oracle，或者改變基于RDBMS數(shù)據(jù)源到LDAP，只需改變模型即可。一旦正確的實(shí)現(xiàn)了模型，不管數(shù)據(jù)來自數(shù)據(jù)庫或是LDAP服務(wù)器，視圖將會(huì)正確的顯示它們。由于運(yùn)用MVC的應(yīng)用程序的三個(gè)部件是相互獨(dú)立，改變其中一個(gè)不會(huì)影響其它兩個(gè)，所以依據(jù)這種設(shè)計(jì)思想能構(gòu)造良好的松耦合的構(gòu)件。

重用性高

隨著技術(shù)的不斷進(jìn)步，現(xiàn)在需要用越來越多的方式來訪問應(yīng)用程序。MVC模式允許使用各種不同樣式的視圖來訪問同一個(gè)服務(wù)器端的代碼，因?yàn)槎鄠€(gè)視圖能共享一個(gè)模型，它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機(jī)來訂購某樣產(chǎn)品，雖然訂購的方式不一樣，但處理訂購產(chǎn)品的方式是一樣的。由于模型返回的數(shù)據(jù)沒有進(jìn)行格式化，所以同樣的構(gòu)件能被不同的界面使用。例如，很多數(shù)據(jù)可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的命令是改變視圖層的實(shí)現(xiàn)方式，而控制層和模型層無需做任何改變。由于已經(jīng)將數(shù)據(jù)和業(yè)務(wù)規(guī)則從表示層分開，所以可以最大化的重用代碼了。模型也有狀態(tài)管理和數(shù)據(jù)持久性處理的功能，例如，基于會(huì)話的購物車和電子商務(wù)過程也能被Flash網(wǎng)站或者無線聯(lián)網(wǎng)的應(yīng)用程序所重用。

生命周期成本低

MVC使開發(fā)和維護(hù)用戶接口的技術(shù)含量降低。

部署快

使用MVC模式使開發(fā)時(shí)間得到相當(dāng)大的縮減，它使程序員（Java開發(fā)人員）集中精力于業(yè)務(wù)邏輯，界面程序員（HTML和JSP開發(fā)人員）集中精力于表現(xiàn)形式上。

可維護(hù)性高

分離視圖層和業(yè)務(wù)邏輯層也使得WEB應(yīng)用更易于維護(hù)和修改。

有利軟件工程化管理

由于不同的層各司其職，每一層不同的應(yīng)用具有某些相同的特征，有利于通過工程化、工具化管理程序代碼。控制器也提供了一個(gè)好處，就是可以使用控制器來聯(lián)接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構(gòu)造應(yīng)用程序提供強(qiáng)有力的手段。給定一些可重用的模型和視圖，控制器可以根據(jù)用戶的需求選擇模型進(jìn)行處理，然后選擇視圖將處理結(jié)果顯示給用戶。

MVC的缺點(diǎn)

沒有明確的定義

完全理解MVC并不是很容易。使用MVC需要精心的計(jì)劃，由于它的內(nèi)部原理比較復(fù)雜，所以需要花費(fèi)一些時(shí)間去思考。同時(shí)由于模型和視圖要嚴(yán)格的分離，這樣也給調(diào)試應(yīng)用程序帶來了一定的困難。每個(gè)構(gòu)件在使用之前都需要經(jīng)過徹底的測(cè)試。

不適合小型，中等規(guī)模的應(yīng)用程序

花費(fèi)大量時(shí)間將MVC應(yīng)用到規(guī)模并不是很大的應(yīng)用程序通常會(huì)得不償失。

增加系統(tǒng)結(jié)構(gòu)和實(shí)現(xiàn)的復(fù)雜性

對(duì)于簡(jiǎn)單的界面，嚴(yán)格遵循MVC，使模型、視圖與控制器分離，會(huì)增加結(jié)構(gòu)的復(fù)雜性，并可能產(chǎn)生過多的更新操作，降低運(yùn)行效率。

視圖與控制器間的過于緊密的連接

視圖與控制器是相互分離，但卻是聯(lián)系緊密的部件，視圖沒有控制器的存在，其應(yīng)用是很有限的，反之亦然，這樣就妨礙了他們的獨(dú)立重用。

視圖對(duì)模型數(shù)據(jù)的低效率訪問

依據(jù)模型操作接口的不同，視圖可能需要多次調(diào)用才能獲得足夠的顯示數(shù)據(jù)。對(duì)未變化數(shù)據(jù)的不必要的頻繁訪問，也將損害操作性能。

一般高級(jí)的界面工具或構(gòu)造器不支持模式

改造這些工具以適應(yīng)MVC需要和建立分離的部件的代價(jià)是很高的，會(huì)造成MVC使用的困難。

總結(jié)

在Java web開發(fā)中，MVC框架充當(dāng)了UI層和業(yè)務(wù)邏輯層的適配器的作用。MVC框架實(shí)現(xiàn)了UI層和業(yè)務(wù)邏輯層最大程度的分離。

總結(jié)

以上是生活随笔為你收集整理的三层架构与MVC的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。