而我發(fā)此文的目的有二：一者，讓初學(xué)者能夠聽到一家之言，是為解惑；二者，更希望拋磚引玉，得到專家的批判。

許多學(xué)生經(jīng)常問我，MVC到底和WEB三層架構(gòu)有啥關(guān)系？ 開始時(shí)，我也只能給他們一些模糊的回答。時(shí)間長了，自己的良心開始受到譴責(zé)。對(duì)于一個(gè)程序員來說，這個(gè)問題顯得挺學(xué)究。我在跟自己的許多程序員朋友以及同 行(Java講師)都對(duì)MVC和WEB三層架構(gòu)的關(guān)系做了探討?，F(xiàn)在可以說對(duì)WEB三層架構(gòu)和MVC之間的關(guān)系理出了頭緒。此可謂教學(xué)相長。

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

• >用戶接口層(UI Layer)
• >業(yè)務(wù)邏輯層(Bussiness Layer)
• >持久化層

?

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

在早期的web開發(fā)中，因?yàn)闃I(yè)務(wù)比較簡單，并沒有這三層的劃分。用戶數(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é)很簡單——增刪改查。但我認(rèn)為，這樣理解實(shí)際上是本末倒置了。對(duì)于簡單數(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ù)邏輯。

灰色地帶

是的，從理論上看，web三層架構(gòu)很美了。但在實(shí)際開發(fā)產(chǎn)品的時(shí)候，我們發(fā)現(xiàn)了很多問題。主要問題就是用UI層和業(yè)務(wù)層之間有許多灰色地帶。這些灰色地帶業(yè)務(wù)邏輯層不想管，UI層也不想管。讓我們舉一些例子:

例子1， 難以管理的頁面跳轉(zhuǎn)關(guān)系

上圖是我在講JSP課程時(shí)，一個(gè)簡單案例的頁面跳轉(zhuǎn)關(guān)系圖。這是一個(gè)十分簡單的例子，但頁面跳轉(zhuǎn)關(guān)系已經(jīng)挺復(fù)雜了。試想，如果你正在做一個(gè)有上百張 表，十幾個(gè)核心模塊，幾百個(gè)頁面的產(chǎn)品時(shí)，這張圖將變得多么復(fù)雜！而問題是，這些頁面跳轉(zhuǎn)關(guān)系分散在JSP和Servlet中，非常難以管理。

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

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

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

例子3，國際化:

如果我們想為不同國家和地區(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)證、國際化等特性。

總結(jié)

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

轉(zhuǎn)載于:https://www.cnblogs.com/Simon-xm/p/3966495.html

總結(jié)

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

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