MVC我一直理解錯了？？

c 改變 m ，m 的改變促使 v 的更新 ，v 操作 c 改變 m

mvc，怎么說呢? 說起來還是比較抽象的。 一般為了層次結(jié)構(gòu)更加清晰，會明確各層的作用。

controller主要請求轉(zhuǎn)發(fā)，model層主要處理業(yè)務(wù)邏輯，有時候也是看業(yè)務(wù)的復(fù)雜程度，如果業(yè)務(wù)相當(dāng)簡單，model顯然有點多余了，model也有人會去直接在view中進(jìn)行use 直接進(jìn)行渲染處理，本身mvc也是基于軟件的變化，而總結(jié)出來的一種經(jīng)驗，其目的也是為了團隊更好的協(xié)同開發(fā)，適應(yīng)復(fù)雜的業(yè)務(wù)等。具體還是要看公司的業(yè)務(wù)的復(fù)雜程度，model層與view的直接交互個人是覺的這種做法欠妥當(dāng)，第一不利于前后端分離，二來代碼可讀性降低，現(xiàn)在更好的做法都是后端提供api接口 前端處理接口。 所以。沒有絕對的mvc 只有適合業(yè)務(wù)變化的mvc。

view和model不交互。

題外話：現(xiàn)在基本用Controller <=> Service <=> Model，多了一個service層，不過個人隨意，我不用service層。 view層也完全獨立成前端了

YII 就是用M去操作V，尤其是用它的小組件的時候，邏輯都在M里

沒有對錯，只要mvc相互分離就行了，是軟件設(shè)計的藝術(shù)

看了以上的回答，都很精彩啊。我以下就說一下我個人的一些理解和想法。

C層，我們從程序功能上來看，主要是用于接收用戶端的數(shù)據(jù)請求，然后返回用戶端請求的，通過C層里的方法把屬于同一個業(yè)務(wù)的東西獨立出來處理。

M層，這層其實主要是數(shù)據(jù)邏輯的處理，最主要的功能其實主要是負(fù)責(zé)數(shù)據(jù)庫的操作，在數(shù)據(jù)庫層面呢，把我們通常的各種數(shù)據(jù)結(jié)構(gòu)拆分成一個表或多個表以二維表的形式來存放。然后這個M層通常是負(fù)責(zé)增刪改查這些基礎(chǔ)操作。不過通常來說，我們這里也會做一些邏輯運算。

V層，相對于后端來說，就是視圖層了，也就是最終要顯示的樣子，但這個V層里通常來說是一些類似于模板性質(zhì)的東西，然后靠C層調(diào)用M層得到結(jié)果，然后扔給一個渲染器，渲染器調(diào)用這個V層的模板把M返回的結(jié)果數(shù)據(jù)填充進(jìn)去就得到一個具體的結(jié)果。

所以通常來說，V層基本上沒有對數(shù)據(jù)的具體處理邏輯，至多就是些for遍歷列表，然后進(jìn)行一次數(shù)據(jù)顯示即可，最多會加些if條件判斷。但是實際在使用的過程中，不可能每個人都遵循這種思路來，可能就直接在View層去調(diào)用model層寫查詢，也可能會有其他的各種邏輯調(diào)用，所以造成View層的意義實際上并不大。

通常來說，MVC的程序，不管做任何操作都要經(jīng)歷過這么一個流程，但是實際上，現(xiàn)代的web有很多異步的交互，而在異步交互的過程來說，其實就只有C層和M層，因為不涉及到后端的數(shù)據(jù)渲染。而現(xiàn)在的各種webAPP或者說是單頁面的開發(fā)方式，restful接口化設(shè)計等，后端可能只有一個C層和model層。在這種情況下來說，通常C層是業(yè)務(wù)邏輯的獨立了，而M層是具體業(yè)務(wù)邏輯中涉及到的細(xì)節(jié)部分的程序。

另外來說，隨著開發(fā)思想的演變，基礎(chǔ)設(shè)計可能通?？雌饋硎且粋€C層和M層，但實際上，可能還有數(shù)據(jù)驗證層，專門做數(shù)據(jù)驗證，異常處理層，專門定義各種異常拋出方式，等等，甚至可能還有跨服務(wù)器通信層。這種情況，M層的話可能就真的只是一個數(shù)據(jù)增刪改查的功能了，而對應(yīng)的C層也只是在外層做一次業(yè)務(wù)邏輯語義化的封裝，而本身具體的實現(xiàn)可能根據(jù)不同的業(yè)務(wù)，編寫方式應(yīng)該是按照設(shè)計模式來理解了。

其實糾結(jié)這些我個人覺得可能意義并不大，重點就是在規(guī)劃程序的時候能有一定的統(tǒng)一標(biāo)準(zhǔn)，同時不喪失程序的課維護性、可擴展性，當(dāng)然，最重要的我覺得就是要加注釋。。。。

題主理解的不錯，一般想到MVC就是這種模式：

1. 用戶在v層觸發(fā)
2. 然后請求c層
3. c層調(diào)用m層獲取數(shù)據(jù)
4. c層再整合數(shù)據(jù)
5. 最后c層調(diào)用v層展示

上面的這種MVC設(shè)計模式，應(yīng)該是最初的MVC設(shè)計模式了。后來隨著編程、設(shè)計模式的多元化，慢慢的在此基礎(chǔ)上（M模型C控制器V視圖）又增加了許多衍生版。

我理解的，MVC就是一個名詞，或者一個代號，一種設(shè)計模式。但是三者之間具體要怎么關(guān)聯(lián)，產(chǎn)生怎么樣的聯(lián)系，不是規(guī)定死的，還是看實際業(yè)務(wù)架構(gòu)的。

首先，MVC 誕生于1979年，可以說，那個時期的電腦和現(xiàn)在的電腦完全不同。那個時候沒有圖形界面，電腦程序非?！敖┯病?，需要操作員輸入一個個指令（通常是鍵盤，也有讀卡器），按照規(guī)定算法進(jìn)行計算，并且返回結(jié)果。所以那個時期的 controller，負(fù)責(zé)接收用戶指令、讀寫數(shù)據(jù)、調(diào)用 view 顯示，即題主你的理解，其實是正確的。

現(xiàn)在幾乎你能夠在網(wǎng)上找到的所有對于 MVC、MVP 之間區(qū)別的講解，幾乎都是作者以“我的理解”，硬解釋出來的，都是錯的。其作者們無一例外全都忽視了計算機和圖形界面的發(fā)展，帶入當(dāng)前的智能設(shè)備、虛擬組件（如按鈕）來解釋 MVC，認(rèn)為 View 能夠接受用戶操作，將指令傳給 controller，然后怎么怎么著。所以看起來都有各種邏輯不通的地方。

我所知道的正確講解，只有這一篇：談?wù)刄I架構(gòu)設(shè)計的演化。其實很簡單，MVP 就是 MVC 的升級版，因為環(huán)境變了，輸入設(shè)備變了，所以模式也變了。

令我失望的是，連 Addy Osami，在《JS設(shè)計模式》一書里，也說錯了。

所以，樓主的理解基本正確。不過最好加上歷史因素，這樣更全面。

另外，現(xiàn)在經(jīng)?？吹降?Guard、service，則是根據(jù)業(yè)務(wù)需求，進(jìn)一步抽象出來的角色和層，不影響 MVC/MVP 體系。