MVC?

MVC是一種設(shè)計模式（Design pattern），也就是一種解決問題的方法和思路，是上世紀80年代提出的，到現(xiàn)在已經(jīng)頗有歷史了。 MVC的意義在于指導開發(fā)者將數(shù)據(jù)與表現(xiàn)解耦，提高代碼，特別是模型部分代碼的復用性。

MVC不僅僅存在于Web設(shè)計中，在桌面程序開發(fā)中也是一種常見的方法。MVC的出現(xiàn)已經(jīng)有一段歷史了。記得我最早了解到MVC的時候，是在Microsoft的Visual C++ 中的MFC中。當時年少無知，以為是MFC中特有的東西。后來隨之不斷學習，才發(fā)現(xiàn)自己的天真。所以說，學得越多，就越覺得自己無知。越覺得自己無知，就越懂得敬畏和謙遜。從這個角度講，同學們，最好不要看不起謙遜的人。

有個這么一個段子，說一天A君在圈內(nèi)聚會時，朋友介紹了另一個人B君互相認識。聚會場合嘛，這很正常，也很普遍。于是AB君小聊了一下。按國人的習慣，A君就問了“先生在哪高就？”。 B君只說了句，“談不上高就，炒炒股?！?“哦，原來是炒股的?！盇君心想，雖沒覺得什么不對，但心理覺得B有點low，只是沒說破，也沒表現(xiàn)出來。過后了一段時間，一次偶然機會，發(fā)現(xiàn)原來B君是國內(nèi)某上市公司的二股東，身家過億。人家沒說慌，確實是炒股的……

話說遠了，我們還說正題。MVC是三個單詞的縮寫：Model, View, Controller。 MVC是一種設(shè)計模式，目前幾乎所有的Web開發(fā)框架都建立在MVC模式之上。當然，最近幾年也出現(xiàn)了一些諸如MVP, MVVM之類的新的設(shè)計模式。但從技術(shù)的成熟程度和使用的廣泛程度來講，MVC仍是主流。

Yii是一個Web框架，從Web開發(fā)的分工來講，Yii的開發(fā)工作中，承擔后端的內(nèi)容多一些，畢竟主要就是PHP開發(fā)。前端主要是在HTML、JavaScript、CSS上進行開發(fā)，然后通過Yii把前端的內(nèi)容管起來，如通過Assets等。這一章要講的MVC，主要是針對后端的。前端的MVC嚴格來講不屬于Yii的范疇，這里我們就不作過多介紹。如果想了解前端的MVC，可以看看Backbone.js Angular.js等前端框架。

MVC的三要素?

MVC是模型(Model)、視圖(View)、控制器(Controller)3個單詞的縮寫。下面我們從這3個方面來講解MVC中的三個要素。

Model是指數(shù)據(jù)模型，是對客觀事物的抽象。如一篇博客文章，我們可能會以一個Post類來表示，那么，這個Post類就是數(shù)據(jù)對象。同時，博客文章還有一些業(yè)務(wù)邏輯，如發(fā)布、回收、評論等，這一般表現(xiàn)為類的方法，這也是model的內(nèi)容和范疇。對于Model，主要是數(shù)據(jù)、業(yè)務(wù)邏輯和業(yè)務(wù)規(guī)則。相對而言，這是MVC中比較穩(wěn)定的部分，一般成品后不會改變。開發(fā)初期的最重要任務(wù)，主要也是實現(xiàn)Model的部分。這一部分寫得好，后面就可以改得少，開發(fā)起來就快。
View是指視圖，也就是呈現(xiàn)給用戶的一個界面，是model的具體表現(xiàn)形式，也是收集用戶輸入的地方。如你在某個博客上看到的某一篇文章，就是某個Post類的表現(xiàn)形式。 View的目的在于提供與用戶交互的界面。換句話說，對于用戶而言，只有View是可見的、可操作的。事實上也是如此，你不會讓用戶看到Model，更不會讓他直接操作Model。你只會讓用戶看到你想讓他看的內(nèi)容。這就是View要做的事，他往往是MVC中變化頻繁的部分，也是客戶經(jīng)常要求改來改去的地方。今天你可能會以一種形式來展示你的博文，明天可能就變成別的表現(xiàn)形式了。
Contorller指的是控制器，主要負責與model和view打交道。換句話說，model和view之間一般不直接打交道，他們老死不相往來。view中不會對model作任何操作， model不會輸出任何用于表現(xiàn)的東西，如HTML代碼等。這倆甩手不干了，那總得有人來干吧，只能Controller上了。 Contorller用于決定使用哪些Model，對Model執(zhí)行什么操作，為視圖準備哪些數(shù)據(jù)，是MVC中溝通的橋梁。

對于MVC中三者的劃分并沒有十分明晰的定義和界線。MVC設(shè)計模式只是一種指導思想，讓你按照model, view, controller三個方面來描述你的應(yīng)用，并通過三者的交互，使應(yīng)用功能得以正常運轉(zhuǎn)。

其中，View的部分比較明確，就是負責顯示嘛。一切與顯示界面無關(guān)的東西，都不應(yīng)該出現(xiàn)在View里面。因此，View中一般不會出現(xiàn)復雜的判斷語句，不會出現(xiàn)復雜的運算過程。對于PHP的Web應(yīng)用而言，毫無疑問，HTML是View中的主要內(nèi)容。這是關(guān)于View的幾個原則：

負責顯示界面，以HTML為主；
一般沒有復雜的判斷語句或運算過程，可以有簡單的循環(huán)語句、格式化語句。比如，一般博客首頁的文章列表，就是一種循環(huán)結(jié)構(gòu)；
從不調(diào)用Model的寫方法。也就是說，View只從Model獲取數(shù)據(jù)，而不直接改寫Model，所以我們說他們老死不相往來。
一般沒有任何準備數(shù)據(jù)的代碼，如查詢數(shù)據(jù)庫、組合成一定格式的字符串等。這些一般放在Controller里面，并以變量的形式傳給視圖。也就是說，視圖里面要用到的數(shù)據(jù)，都是拿來就能直接用的變量。

對于Model而言，最主要就是保存事物的信息，表征事物的行為和對他可以進行的操作。比如，Post類必然有一個用于保存博客文章標題的title屬性，必然有一個刪除的操作，這都是Model的內(nèi)容。以下是關(guān)于Model的幾個原則：

數(shù)據(jù)、行為、方法是Model的主要內(nèi)容；
實際工作中，Model是MVC中代碼量最大，邏輯最復雜的地方，因為關(guān)于應(yīng)用的大量的業(yè)務(wù)邏輯也要在這里面表示。
Model所提供的數(shù)據(jù)都是原始數(shù)據(jù)。也就是說，不帶有任何表現(xiàn)層的代碼。比如，一般不會在輸出的數(shù)據(jù)中添加HTML標簽，這是View的工作。但是Model可以提供有結(jié)構(gòu)的數(shù)據(jù)，數(shù)組結(jié)構(gòu)、隊列結(jié)構(gòu)、乃至其他Model等。這個結(jié)構(gòu)并非是表現(xiàn)層的格式，而是數(shù)據(jù)在內(nèi)存中的表現(xiàn)。
與輸出不同，Model的輸入數(shù)據(jù)，可以是帶有表現(xiàn)格式的數(shù)據(jù)。如將一篇文章保存到Post里面，內(nèi)容中必然包含各種HTML標簽。因此，Model一般要對輸入數(shù)據(jù)作過濾、驗證和規(guī)范化等預處理。特別是對于需要保存進數(shù)據(jù)庫的，一定要對所有的輸入數(shù)據(jù)作預處理。這些預處理，有的其實是業(yè)務(wù)邏輯。比如只有主編才可以刪除文章，這一驗證規(guī)則既也是業(yè)務(wù)邏輯，也是權(quán)限控制。而有些預處理，則不屬于業(yè)務(wù)邏輯，比如，文章標題前后的空格應(yīng)去除。
注意與Controller區(qū)分開。Model是處理業(yè)務(wù)方面的邏輯，Controller只是簡單的協(xié)調(diào)Model和View之間的關(guān)系，只要是與業(yè)務(wù)有關(guān)的，就該放在Model里面。好的設(shè)計，應(yīng)當是胖Model，瘦Controller。

對于Controller，主要是響應(yīng)用戶請求，決定使用什么視圖，需要準備什么數(shù)據(jù)用來顯示。以下是有關(guān)Controller的設(shè)計原則：

用于處理用戶請求。因此，對于reqeust的訪問代碼應(yīng)該放在Controller里面，比如 $_GET $_POST 等。但僅限于獲取用戶請求數(shù)據(jù)，不應(yīng)該對數(shù)據(jù)有任何操作或預處理，這些工作應(yīng)該交由Models來完成。
調(diào)用Models的讀方法，獲取數(shù)據(jù)，直接傳遞給視圖，供顯示。當涉及到多個Model時，有關(guān)的邏輯應(yīng)當交給Model來完成。
調(diào)用Models的類方法，對Models進行寫操作。
調(diào)用視圖渲染函數(shù)等，形成對用戶Reqeust的Response。

Model設(shè)計參考?

在MVC中，Model排第一，是有一定暗示的。一是Model是整個架構(gòu)中，代碼量最大，復用程度最高，也是最體現(xiàn)程序員設(shè)計功力的地方。二是View和Controller相對于Model而言，在實際開發(fā)中，復用程度不高，邏輯復雜程度較低。可以說，Model設(shè)計得好，整個MVC就好，應(yīng)用開發(fā)起就順。

因此，這一節(jié)將以Model為核心，來講MVC的設(shè)計。實話說，MVC盡管提出了Model View Controller的劃分思想，但到了具體實操中，并不是很好把握的。下面介紹的設(shè)計參考，也僅僅是個人在實際項目中的一些體會和想法，僅作參考。在具體設(shè)計中，可以后把握這么幾點：

Model應(yīng)當集中整個應(yīng)用的數(shù)據(jù)和業(yè)務(wù)邏輯?

應(yīng)用當中涉及到的所有業(yè)務(wù)對象都應(yīng)盡可能抽像成Model。如，博客系統(tǒng)當中，文章要抽象成Post，評論要抽象成Comment。而相關(guān)的業(yè)務(wù)邏輯，如發(fā)布新文章可以用 Post::create() ，刪除評論可以用 Comment::delete() 。這樣子整個應(yīng)用就顯得很清晰明了。

基礎(chǔ)Model應(yīng)當盡可能細化?

在一個應(yīng)用中，特別是對于大型復雜應(yīng)用，Model間關(guān)系可能比較復雜。在構(gòu)造應(yīng)用時，特別是基礎(chǔ)Model時，要從足夠小的粒度來設(shè)計。此時，就要考慮采取繼承、封裝等措施了。比如，一個博客文章Post，一般包含了若干標簽，在頁上一般寫在作者、日期等Post字段的旁邊。從邏輯上來看，把標簽作為Post的一個屬性，是說得通的。但是如果把標簽作為一個屬性像標題、正文等字段一樣依附于Post。那么在有的功能上，實現(xiàn)起來是有難度的。比如，客戶要求，當一個Post含有標簽 “yii, model” 時，可以點擊 “yii” ，然后系統(tǒng)列出所有具標簽中含有 “yii” 的文章。

為了實現(xiàn)這個功能，正確的設(shè)計是單獨將標簽抽象成Tag。這樣，Post和Tag是多對多的關(guān)系，即一個Post有多個Tag，一個Tag也對應(yīng)多個Post。這個多對多關(guān)系可以通過一張數(shù)據(jù)表 tbl_post_tag 來表示。接下來，為Post增加 Post::getTags() 方法，并通過 tbl_post_tag 表來查詢當前Post的所有標簽。同時，為Tag增加 Tag::getPosts() 方法，也通過 tbl_post_tag 表來查詢當前Tag對應(yīng)的文章。這樣，就具備了實現(xiàn)客戶要求的新功能的基礎(chǔ)。

因此，在Model設(shè)計上，要以盡量小的粒度進行設(shè)計。一般而言，粒度越小，復用的可能性就越高。

有的讀者可能會問了，既然要求粒度盡可能地小，那么，Post是不是也應(yīng)當再細化，把段落抽象為Model？是否有這個必要，看客戶需求。一般情況確實沒有這必要，如果這么做，那是不是再以句子為單位進行抽象？但如果客戶要求這個博客系統(tǒng)的評論是針對段落進行的評論的，要將評論顯示在對應(yīng)的段落旁邊，甚至顯示每個段落評論人次等功能。那么就需要把段落抽象成Model了。

分層次設(shè)計Model?

從設(shè)計流程上，數(shù)據(jù)庫結(jié)構(gòu)設(shè)計與Model的設(shè)計是緊密相關(guān)的。先有數(shù)據(jù)庫結(jié)構(gòu)設(shè)計，后有Model設(shè)計。在設(shè)計數(shù)據(jù)庫結(jié)構(gòu)的時候，也是在設(shè)計Model。一般而言，最單元、粒度最小的Model就是根據(jù)每個數(shù)據(jù)庫表所生成的Model，這往往是個Active Record。

比如標簽的問題，在數(shù)據(jù)庫存儲過程中，Post和Tag是分開存的，而且這兩個表的字段，沒有冗余。 tbl_post_tag 表也只記錄他們的ID，沒有實質(zhì)內(nèi)容。

在獲取數(shù)據(jù)渲染視圖，向用戶展現(xiàn)時，這兩個Model及他們的字段，是完全夠用，且沒有冗余的。

那么，能不能說 Post 和 Tag 這兩個Model是夠用的呢？顯然還不夠。

當用戶在創(chuàng)建文章、修改文章、審核文章時，需要采用一個表單來顯示來收集用戶輸入。其中，對于標簽的采集，一般是一個長條的文本框，讓用戶一次性輸入多個標簽，并以 , 等進行分隔的。

但是，這個文本框沒有一個字段與之進行對應(yīng)。我們也沒辦法對這個字段的用戶輸入進行任何的驗證、預處理。

因此，Post的功能是不夠用的。不夠用怎么辦？那就加吧。但直接在 Post 里面加個 public $tagString 并不好。畢竟只是在使用表單時，才會有這個問題，其他場合，這個字段是沒用的。

這種情況下，一般使用繼承:

public class PostForm extends Post{    public $tagString;    ... ...}

這樣，當控制器發(fā)現(xiàn)用戶在創(chuàng)建、修改、審核文章時，可以使用 PostForm Model來渲染視圖了，而其他場合則仍使用Post。這樣就在需要時，增加了一個 tagString 的字段用于收集用戶輸入的標簽。

在具體設(shè)計過程中，由于Model本身就會包含很多代碼，因此，要多使用這繼承等手段，把代碼組織好。

仔細為Model方法命名?

由于Model的代碼量比較大，又集中了大量的邏輯，因此，會在一個Model中有大量的方法。仍然以Post為例，會涉及到創(chuàng)建、審核、發(fā)布、回收等流程，相關(guān)的方法比較多，在命名上要用心。可能會涉及到的、名字又比較接近的方法就有：

getPrevPost()，前一篇文章，用于導航
getNextPost()，下一篇文章，用于導航
getRelatedPosts($n = 10)，獲取相關(guān)的N篇文章，用于相關(guān)文章推薦列表
getPostsOfAuthor($n = 10)，獲取同一作者的N篇相關(guān)文章，用于作者文章列表
getLatestPosts($n = 10)，最新的N篇文章，靜態(tài)方法，用于文章列表或RSS輸出
getHotestPosts($n = 10)，最熱門的N篇文章，靜態(tài)方法，用于熱門文章列表
getPublishPosts($n = -1)，獲取已經(jīng)發(fā)布的N篇文章，靜態(tài)方法，用于文章列表
getDraftPosts($n = -1)，獲取未發(fā)布的N篇文章，靜態(tài)方法，用于作者頁面

這里只是一些獲取其他Post的方法，命名比較合理，一看就知道意思。而且全部寫成getter的形式，可以使用讀取屬性的方式進行訪問。

不單單是在Model方法的命名上要用心，在變量名、類名、方法名等的命名上，也要養(yǎng)成習慣，形成規(guī)律。不要圖一時之快，胡亂起名。否則，出來混，遲早要還的。

MVC與前后端的配合?

從MVC的起源來講，是從桌面應(yīng)用的開發(fā)中發(fā)展起來的。從本質(zhì)來講，這是一種解決問題的思路和辦法。從實踐來講，這是一種久經(jīng)考驗的有效方式。但是如開頭我們講的，Yii更多的是側(cè)重于后端。對于Web應(yīng)用而言，包含Yii在內(nèi)的許多Web開發(fā)框架，都是沒有辦法知道用戶的操作，如鼠標、鍵盤等操作的。 Web應(yīng)用想要了解用戶的操作，只能依靠用戶發(fā)送Request。而對于鼠標、鍵盤等的響應(yīng)，只能依靠前端技術(shù)，如JavaScript等來實現(xiàn)。

再加上這幾年來Web瀏覽器的功能日臻強大。因此，Web應(yīng)用開發(fā)出現(xiàn)了一個新的發(fā)展苗頭，就是功能從后端往前端轉(zhuǎn)移。

在前端，通過JavaScript捕獲用戶操作，進行相應(yīng)處理。或是發(fā)送回后端獲取響應(yīng)后處理，如通過ajax請求后端數(shù)據(jù)，實現(xiàn)無刷新的局部頁面更新，向用戶進行反饋；或直接在前端由瀏覽器進行處理，如使用backbone.js、Angular.js等前端框架的數(shù)據(jù)綁定功能等。這些都使得Web應(yīng)用表現(xiàn)得越來越像桌面應(yīng)用。

后端MVC也在為前后端的發(fā)展而改變。 Controller的功能更多的變成了識別是ajax請求還是普通請求，并根據(jù)請求的不同采取相應(yīng)的視圖渲染方式。對于普通請求，正常渲染視圖，輸出HTML。對于ajax請求，則返回局部渲染視圖，輸出HTML片段。有的甚至輸出XML或者JSON。唯一在大潮流中，巍然不動的，還是我們的大Model。

本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請點擊舉報。

免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版