一件事，要知其然往往很簡單，要知其所以然通常不是那么容易，就如最近重新鞏固spring的過程中，就覺得還有許多問題其實并不是十分明了。

屈指一算，手頭上做過的正式項目也有了四五六七個了，不管用的數(shù)據(jù)庫和其他一些細節(jié)上的技術如何，總的來說大的框架結構都是差不多的。
說白了，也就是mvc和三層結構。

而mvc和三層結構究竟是什么關系，我曾在面試的過程中被人問過幾次，也曾仔細的想過、查過這個問題，但是直到此時，我也還是不能完全確定。

只不過隨著時間的積累，隨著技術的沉淀，隨著視野的拓寬，我大體上認同了兩種說法，不管別人怎么看，我個人是覺得兩種說法都有道理，歡迎對這個問題有不同看法的朋友一起討論。

三層結構是什么，是展現(xiàn)層、應用層、數(shù)據(jù)訪問層，這個基本上是沒有太大的異議的，兩種看法的來源基本上都是來自對于mvc的理解。

對于Java web應用來說，不管是B/S還是C/S，大體上都可以分成服務端和客戶端兩部分，只不過B/S的客戶端就是公用的瀏覽器。

基于這種大的架構，有一種對于mvc的說法就是：

m是model，也就是和數(shù)據(jù)庫相關的那些，比如實體類和dao、mapper.xml等，
對應著三層結構的數(shù)據(jù)訪問層；
v是view，也就是前臺的頁面或者說是客戶端展示給用戶看的東西，也就是展現(xiàn)層；
而c就是controller以及service等具體的業(yè)務邏輯，對應著三層結構的應用層。

• 1

• 2

• 3

• 1

• 2

• 3

這種說法我覺得應該是為了對應而對應，就是要把mvc和三層結構的關系一一對應起來，因此也差不多就是一個對應一個。

或許是經(jīng)驗還不夠多的緣故，或許本來就是這樣子，反正我是覺得這種說法正確，或者更確切的說，這是大的mvc。

那么還有一種說法可能就不是像上邊這樣一一對應了，大體上的說法是這樣的：

我們通常所說的mvc實際上只是對應了三層結構中的展現(xiàn)層，也就是view而已，然后v是
客戶端，m是實體，c是controller。
至于三層結構中的應用層和數(shù)據(jù)訪問層則是分別對應了后臺代碼中的service和dao。

• 1

• 2

• 1

• 2

而對于這種說法，為什么我覺得有道理呢？是因為按照這種描述，就是和前臺展示直接相關的東西都放在展現(xiàn)層。

*比如controller要直接和url打交道，而很多時候返回給客戶端的數(shù)據(jù)也會封裝成對象的形式，經(jīng)常就是model；也就是說不管是controller還是model，都實打實和用戶看得到的部分相關，就劃為了展現(xiàn)層。

只不過在某些時候，就比如我們現(xiàn)在的項目中，為了進一步的實現(xiàn)松耦合，我們會創(chuàng)建一個command類，類似于實體model，然后用model操作數(shù)據(jù)庫，用command和前臺打交道，道理是一樣的。

而在另一方面，我們現(xiàn)在項目前端使用的技術是angular js，這項技術現(xiàn)在也說實現(xiàn)了前臺的mvc，有controller、service，還有數(shù)據(jù)層。

因此在這種情況下，我個人就覺得，mvc本就是一個概念，重要的是一種理解，它本身的作用只是為了實現(xiàn)松耦合，而不是為了mvc而mvc，未必一定要有一個唯一的答案！

以下是我覺得比較好的其他理解：
來自百度百科的說法，是否是標準？

MVC（模型Model-視圖View-控制器Controller）是一種架構模式，可以用它來創(chuàng)建在域對象和UI表示層對象之間的區(qū)分。

同樣是架構級別的，相同的地方在于他們都有一個表現(xiàn)層，但是他們不同的地方在于其他的兩個層。

在三層架構中沒有定義Controller的概念。這是最不同的地方。而MVC也沒有把業(yè)務的邏輯訪問看成兩個層，這是采用三層架構或MVC搭建程序最主要的區(qū)別。當然了。在三層中也提到了Model，但是三層架構中Model的概念與MVC中Model的概念是不一樣的，“三層”中典型的Model層是以實體類構成的，而MVC里，則是由業(yè)務邏輯與訪問數(shù)據(jù)組成的。

這是來自百度知道的說法，是否專業(yè)？

MVC和三層架構有什么區(qū)別就是MVC是最流行的三層架構中的一種框架，就是模型-視圖-控制器三者分離。

MVC模式（Model–view–controller）是軟件工程中的一種軟件架構模式，把軟件系統(tǒng)分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。

MVC模式最早由Trygve Reenskaug在1978年提出[1] ，是施樂帕羅奧多研究中心（Xerox PARC）在20世紀80年代為程序語言Smalltalk發(fā)明的一種軟件架構。

MVC模式的目的是實現(xiàn)一種動態(tài)的程式設計，使后續(xù)對程序的修改和擴展簡化，并且使程序某一部分的重復利用成為可能。除此之外，此模式通過對復雜度的簡化，使程序結構更加直觀。軟件系統(tǒng)通過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。

專業(yè)人員可以通過自身的專長分組：
控制器（Controller）- 負責轉發(fā)請求，對請求進行處理。 視圖（View） - 界面設計人員進行圖形界面設計。 模型（Model）

程序員編寫程序應有的功能（實現(xiàn)算法等等）、數(shù)據(jù)庫專家進行數(shù)據(jù)管理和數(shù)據(jù)庫設計(可以實現(xiàn)具體的功能)。

來自來看日出的評論，我覺得有道理

無意中看到這個問題，我前段時間也想了很久，今天看到有點感觸，不知道您怎么看，我一直其實有疑惑的(一個剛參加工作的新人)對于mvc的三層架構，設計理念是為了實現(xiàn)高內聚低耦合，您說得第一種三層結構，我覺得其實并沒有達到這個低耦合的效果。

因為在應用層處理業(yè)務時，并沒有將真正的業(yè)務邏輯和數(shù)據(jù)庫邏輯分離開來，僅僅將視圖和邏輯分離開了，并沒有達到低耦合的效果，個人覺得這并不是真正的MVC。

個人的理解，mvc應該分為5層。

1.視圖層(html/jsp/)等用戶能看得到的信息，數(shù)據(jù)信息的開始和結束。

2.控制層(servlet/action),控制層不處理任何業(yè)務(包括業(yè)務邏輯和數(shù)據(jù)庫邏輯)，只為控制流程，實現(xiàn)跳轉功能，只調用service層的結果實現(xiàn)跳轉功能，控制層的邏輯更偏向視圖層，為視圖層提供服務。

3.服務層(service)：專門處理業(yè)務邏輯，是控制層和DAO的中間過渡層，根據(jù)DAO層的返回結果的不同，處理不同的業(yè)務邏輯，并將結果向上返回給控制層。

4.DAO層：專門處理各種數(shù)據(jù)庫邏輯，包括對數(shù)據(jù)庫的CRUD，存儲過程/函數(shù)各種操作，提供訪問數(shù)據(jù)庫的接口，DAO層更偏向于model。

5.數(shù)據(jù)模型層：專門封裝數(shù)據(jù)原始模型(javabean/DTO)，本身不提供任何對數(shù)據(jù)庫的操作，只提供接口供DAO層調用數(shù)據(jù)。 從上到下依次為視圖層，控制層，服務層，DAO層，數(shù)據(jù)模型層。 個人理解，新人剛入門，有錯誤的地方希望指出共同學習。

我對來看日出的回復如下：

實際上，我個人現(xiàn)在的觀點是，我覺得我說的兩種都有道理，而你說的這一種也有道理，只看出發(fā)點是什么，能不能說通。

你的這種說法，應該是實際開發(fā)時的代碼結構，后端通常有model、dao、service、controller，但是現(xiàn)在的前端，就比如我們用的angular js，實際上也分成了數(shù)據(jù)模型層、servie層、controller層、html展示層。

因此，我的理解是，網(wǎng)上常見的mvc解釋應該是針對之前整個系統(tǒng)架構比較簡單的情況，而現(xiàn)在前后端各種架構和技術都復雜起來了，可能便不能再這樣簡單的對應。

也就是說，我說的兩種實際上對于現(xiàn)在的情況可能都不對了。

隨著工作時間的增長，我對這個問題的看法一直在變，或許就是那句“看山是山，然后看山不是山，然后看山是山”，理解性的東西，本來就會隨著個人的閱歷增長而變化，今天覺得對的可能明天就覺得錯了。

所以，歸根結底，我覺得可以回到主題：我覺得對錯不重要，重要的是能不能說通，是不是自己的理解，對也好，錯也罷，能說的有理有據(jù)就夠了，因為理解會變。

覺得本文有幫助？請分享給更多人

關注「猿助猿」成就頂級開發(fā)

總結

以上是生活随笔為你收集整理的java中的mvc三层结构究竟有什么关系的全部內容，希望文章能夠幫你解決所遇到的問題。

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