建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
當(dāng)然這種架構(gòu)模式本身的一些問(wèn)題也會(huì)在接下來(lái)的內(nèi)容就加以介紹，另外就是如果大家有什么不同觀點(diǎn)的話(huà)，歡迎拍磚（只要不打臉就行，呵呵）。
在衛(wèi)東等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專(zhuān)注、極致的服務(wù)理念，為客戶(hù)提供網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站制作 網(wǎng)站設(shè)計(jì)制作定制制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),全網(wǎng)整合營(yíng)銷(xiāo)推廣,外貿(mào)營(yíng)銷(xiāo)網(wǎng)站建設(shè),衛(wèi)東網(wǎng)站建設(shè)費(fèi)用合理。
一. MVC是誰(shuí)提出的
模型－視圖－控制器（MVC）是Xerox PARC在八十年代為編程語(yǔ)言Smalltalk－80發(fā)明的一種軟件設(shè)計(jì)模式，至今已被廣泛使用。最近幾年被推薦為Sun公司J2EE平臺(tái)的設(shè)計(jì)模式，并且受到越來(lái)越多的使用 ColdFusion 和 PHP 的開(kāi)發(fā)者的歡迎。模型－視圖－控制器模式是一個(gè)有用的工具箱，它有很多好處，但也有一些缺點(diǎn)。
二. MVC是否適合進(jìn)行大項(xiàng)目的開(kāi)發(fā)
MVC框架肯定是適合于做大項(xiàng)目開(kāi)發(fā)的，但并不是說(shuō)有了MVC框架我們就可以開(kāi)發(fā)大項(xiàng)目，聽(tīng)起來(lái)有些繞，其實(shí)道理很簡(jiǎn)單，原因就是人（開(kāi)發(fā)者）。如果你是一個(gè)對(duì)MVC框架的設(shè)計(jì)理念有深入研究的人，那么你在使用MVC框架進(jìn)行產(chǎn)品和項(xiàng)目開(kāi)發(fā)的時(shí)候就會(huì)隨時(shí)隨地都要考慮一些問(wèn)題：
1.低耦合性（強(qiáng)調(diào)視圖層和業(yè)務(wù)層分離）
2.可測(cè)試性（這個(gè)非常重要）
3.高重用性和可適用性
4.有利于軟件工程化管理等等。
這里我很欣賞老趙的治學(xué)態(tài)度，因?yàn)樵谒奈恼潞痛a中隨時(shí)隨地都在進(jìn)行著思考，特別是其對(duì)可測(cè)試性，單元測(cè)試（這里不是什么TDD）的思考，讓我看起來(lái)有心靈相通的感覺(jué)。因?yàn)檫@些問(wèn)題都是在做中型甚至大型項(xiàng)目中要認(rèn)真思考的，決不是說(shuō)微軟給的例子就是我們的唯一準(zhǔn)則，必定里面有對(duì)也有錯(cuò)，我相信在MVC面前，國(guó)內(nèi)甚至微軟內(nèi)部的牛人都不是很多。
說(shuō)了這些，大家可以意識(shí)到了，如果在沒(méi)有理解下面這張圖以及對(duì)MVC的“所謂優(yōu)點(diǎn)是從何處得到的”有認(rèn)識(shí)，而一上來(lái)就去拿MVC去開(kāi)發(fā)大型項(xiàng)目的話(huà)，我想不僅不能發(fā)揮asp.net MVC框架的估勢(shì)，相反會(huì)時(shí)時(shí)受制于里面的約束，配置和功能特性，最后感覺(jué)還不如直接用asp.net webform開(kāi)發(fā)來(lái)的直接，不是嗎？真要是到了這一境地，我想不僅無(wú)法使用MVC進(jìn)行大型目開(kāi)發(fā)，就連中小企業(yè)應(yīng)用都應(yīng)付不來(lái)。
三. 能不能使用MVC架構(gòu)進(jìn)行Webform的開(kāi)發(fā)
有人嘗試使用ASP.NET MVC 框架來(lái)進(jìn)行webform方式的開(kāi)發(fā)，我個(gè)人是不欣賞這種做法的，這就好比在使用LINQ的項(xiàng)目中又同時(shí)使用SQL語(yǔ)句一樣“怪異”，這在代碼的整體風(fēng)格上會(huì)讓人產(chǎn)生迷惑，不是嗎？當(dāng)然老趙也在他的視頻課程中提到在webform頁(yè)面中使用一些MVC功能（比如：ModelBinder等），但我想老趙的本意決不是讓這種混合方式的開(kāi)發(fā)大行其道，必定這是“非主流”，所以孰輕孰重還是要大家自己把握的。
四. 傳統(tǒng)的三（N）層架構(gòu)與MVC，以及MVC與MVP關(guān)系
本文所說(shuō)的三層架構(gòu)指：表現(xiàn)層（顯示層）， 業(yè)務(wù)邏輯層， 數(shù)據(jù)訪問(wèn)層（持久化）。如果大家非要“生搬硬套”的把它與MVC扯上關(guān)系的話(huà)，那我就只能在這里"強(qiáng)扭這個(gè)瓜"了，即：
三層架構(gòu)中"表現(xiàn)層"的aspx頁(yè)面對(duì)應(yīng)MVC中的View（繼承的類(lèi)不一樣）
三層架構(gòu)中"表現(xiàn)層"的aspx.cs頁(yè)面(類(lèi))對(duì)應(yīng)MVC中的Controller,理解這一點(diǎn)并不難，大家想一想我們以前寫(xiě)過(guò)的Redirect，當(dāng)然它本身就是跳轉(zhuǎn)了一些鏈接頁(yè)面，而MVC中的Controller要做的更爽，它控制并顯示輸出了一個(gè)視圖。即然所起到的作用都是對(duì)業(yè)務(wù)流程和顯示信息的控制，只不過(guò)是實(shí)現(xiàn)手段不同而已。
三層架構(gòu)中業(yè)務(wù)邏輯層和數(shù)據(jù)訪問(wèn)層對(duì)應(yīng)MVC中的Model(必定View和Controller已找到“婆家”，剩下的Model只能是業(yè)務(wù)業(yè)務(wù)層和數(shù)據(jù)訪問(wèn)層的了，呵呵)。但其實(shí)微軟的一些MVC示例項(xiàng)目中對(duì)這個(gè)問(wèn)題理解的并不是這樣簡(jiǎn)單，這一點(diǎn)在我之前的關(guān)于兩個(gè)MVC示例的思考(MVCStore和Oxite) 已闡述過(guò)，就不多說(shuō)了。
其實(shí)明白了這個(gè)關(guān)系，就可以嘗試把以前的三層結(jié)構(gòu)遷移到MVC框架下，當(dāng)然在這個(gè)過(guò)程中肯定會(huì)遇到這樣或那樣的問(wèn)題，但原則就是把將MVC的優(yōu)勢(shì)發(fā)揮到極致，要不然還不如不做。說(shuō)到這里，其實(shí)早在N年前就有人提出使用FrontController（前端控制器）來(lái)實(shí)現(xiàn)對(duì)HTTP頁(yè)面請(qǐng)求的路由跳轉(zhuǎn)（包括數(shù)據(jù)的展現(xiàn)），說(shuō)白了就是使用HttpHandler來(lái)進(jìn)行頁(yè)面請(qǐng)求的處理和數(shù)據(jù)綁定，而不是完全“指望”普通的頁(yè)面訪問(wèn)重定向等。這樣做的目的，就我而言與Routing中的Controller和Action的出發(fā)點(diǎn)標(biāo)是一致的，只不過(guò)Routing實(shí)現(xiàn)的更優(yōu)雅同時(shí)也更底層一些。
說(shuō)完了三層架構(gòu)，再看看MVC與MVP，其實(shí)在這之前我們有必要看一下這張圖:
看完了上面的圖，大家就會(huì)發(fā)現(xiàn)MVP與MVC最大的一個(gè)區(qū)別就是“Model與View層之間倒底該不該通信（甚至雙向通信，如圖）。我想這也是目前做這兩方面研究的專(zhuān)家所互相爭(zhēng)論的戰(zhàn)場(chǎng)。必定各有各的好處和因好處要付出的代價(jià)。起碼在MVP模式下的Presenter要擁有“絕對(duì)權(quán)力”。如果沒(méi)有它，MODEL與View就是兩個(gè)孤島，盡管各有各的地盤(pán)（完全解耦），但不會(huì)給企業(yè)帶來(lái)什么有用的價(jià)值。所以我這里有一個(gè)比喻來(lái)形容MVP中的：
Presenter ----就是一個(gè)控制欲極強(qiáng)的女人，甚至就連“用什么姿勢(shì)”，它都要管一管。
當(dāng)然日里萬(wàn)機(jī)操心多了就會(huì)讓自己要做的事越來(lái)越多，最終它面臨的就是該層代碼日益龐雜，且書(shū)寫(xiě)起來(lái)不太方便，必定就連事件綁定這類(lèi)雞毛算皮的事都要?dú)w它管，累不累呀。最終我們看到MVP中的View就真的代碼輕閑了不少（國(guó)企職工嘛），難怪說(shuō)View只要從相應(yīng)的IVIEW接口下實(shí)現(xiàn)相應(yīng)的屬性和一些簡(jiǎn)單方法就完事了，而最終調(diào)用IVIEW接口下的那個(gè)視圖實(shí)例則完全交給了Presenter，這讓我想到了MVC中可以支持“自定義模版引擎（最終由MVC框架來(lái)控制使用系統(tǒng)還是自定義的模版引擎）”以及平時(shí)大家常掛在嘴邊的換膚功能，想到這里多少還真有那么點(diǎn)意思了（精神層面上）。
當(dāng)然在微軟內(nèi)部對(duì)MVP的理解也有所不同，如下圖中所說(shuō)的Supervising Controller模式和上面大家看到的PassiveView.
Supervising Controller模式其實(shí)很接近于MVC的那張圖了，只是又提供了Presenter與View之間的“雙向通信”。這種做法也是有很多不同意見(jiàn)的，起碼對(duì)那些支持“單向依賴(lài)”的開(kāi)發(fā)者而言是“嗤之以鼻”的。
說(shuō)到這里，表達(dá)一下我的觀點(diǎn)，我是偏向于PassiveView的，雖然這種模式有些霸道，但必定是讓Model和View之間真正解耦，為開(kāi)發(fā)者提供了最大的“控制成就感”，可以說(shuō)想怎么控制視圖就怎么控制，但因此所造成的問(wèn)題就是代碼書(shū)寫(xiě)量和實(shí)現(xiàn)復(fù)雜性等問(wèn)題了。
五. Controller和Model中該有哪些東東
因?yàn)閂IEW中的邏輯比較簡(jiǎn)單，所以對(duì)系統(tǒng)復(fù)雜性的考慮基本上要重點(diǎn)放在Model中，而Controller是對(duì)業(yè)務(wù)流程的控制，其應(yīng)該保持“代碼清爽”。說(shuō)是這么說(shuō)，但實(shí)際進(jìn)行項(xiàng)目開(kāi)發(fā)時(shí)這兩者之間的界線能這么清楚嗎，答案是“盡量保（堅(jiān)）持”。必定這是MVC的“特色”嘛。
另外這里向大家推薦一個(gè)不錯(cuò)的方法"Robustness"，有了它您就可以很容易的找出那些系統(tǒng)方法要放在MODEL中，哪些該歸入控制邏輯中了，該方法我在兩年前的一篇文章中提到過(guò)，大家感興趣的話(huà)可以看看這個(gè)鏈接, 采用[ICONIX] 方法實(shí)踐BLOG設(shè)計(jì)之四 [健壯性分析] .其核心內(nèi)容如下：
實(shí)體對(duì)象(entity object):
通常是來(lái)自域模型中的對(duì)象(也就是現(xiàn)實(shí)世界)，它常對(duì)應(yīng)于數(shù)據(jù)庫(kù)表和文件，這些數(shù)據(jù)表和文件中存儲(chǔ)了執(zhí)行用例所需的數(shù)據(jù)。有些實(shí)體對(duì)象是“臨時(shí)”對(duì)象（如搜索結(jié)果），當(dāng)用例結(jié)束后將消失。
邊界對(duì)象(boundary object)：
參與者使用它來(lái)同系統(tǒng)交互，這通常包含窗口，屏幕，對(duì)話(huà)框和菜單。如果有GUI原型，將會(huì)知道許多主要的邊界對(duì)象是什么。
控制對(duì)象(control object):
將邊界對(duì)象和實(shí)體對(duì)象關(guān)聯(lián)起來(lái)（通常被稱(chēng)為控制器，因?yàn)樗鼈兺ǔ２皇钦嬲膶?duì)象），它包含了大部分應(yīng)用邏輯，它們?cè)谟脩?hù)和存儲(chǔ)的數(shù)據(jù)之間架起一座橋梁?？刂茖?duì)象中包含經(jīng)常修改的業(yè)務(wù)規(guī)則和策略。這樣修改只需要在這些對(duì)象中進(jìn)行，而不會(huì)涉及到用戶(hù)界面和數(shù)據(jù)庫(kù)模式。控制器偶爾 (20%的時(shí)間內(nèi))也會(huì)是設(shè)計(jì)中的“真正對(duì)象”，但大部分時(shí)間內(nèi)，控制器只是一個(gè)占位符，用于避免您遺漏用例要求的任何功能和系統(tǒng)行為。
上面的三個(gè)對(duì)象分別對(duì)應(yīng)Model, View, Controller.
正如文中所說(shuō)，該方法還提供了如下好處：
1.它幫助您確保用例文本的正確性，且沒(méi)有指定不合理或不可能的行為 (基于要使用的一組對(duì)象)，從而提供了健康性檢查。
2.幫助確保用例考慮了所有必需的分支流程，從而提供了完整性和正確性檢查。
3.讓您能夠(持續(xù))發(fā)現(xiàn)對(duì)象，因?yàn)樵谟蚪Ｆ陂g可能會(huì)遺漏一些對(duì)象， 而這些對(duì)象在繪制時(shí)序圖時(shí)不易被發(fā)現(xiàn)，并且很可能正是它導(dǎo)致無(wú)法繪制時(shí)序圖。
4.縮小分析和設(shè)計(jì)的鴻溝，從而最終完成初步設(shè)計(jì)(關(guān)于初步設(shè)計(jì)復(fù)核會(huì)在下一篇中介紹)。
六.MVC與MVP是否可以同時(shí)出現(xiàn)在一個(gè)SLN甚至一個(gè)項(xiàng)目中
這一點(diǎn)我想誰(shuí)說(shuō)了都不算數(shù)，只有用戶(hù)需求才是王道，用戶(hù)使用在當(dāng)前項(xiàng)目中實(shí)現(xiàn)某些特定功能，而該功能恰恰是MVC或MVP的用武之地，那就一個(gè)字：“用”。
最后還要再說(shuō)明一點(diǎn)：
業(yè)務(wù)邏輯是系統(tǒng)架構(gòu)中體現(xiàn)核心價(jià)值的部分。它的關(guān)注點(diǎn)主要集中在業(yè)務(wù)規(guī)則的制定、業(yè)務(wù)流程的實(shí)現(xiàn)等與業(yè)務(wù)需求有關(guān)的系統(tǒng)設(shè)計(jì)，所以說(shuō)一個(gè)系統(tǒng)來(lái)說(shuō)，業(yè)務(wù)邏輯是無(wú)處不在的。View上的是顯示邏輯，Controller上是流程控制邏輯)，Model上簡(jiǎn)直就是“邏輯大本營(yíng)”了。
使用 MVC 框架時(shí)我們要將“經(jīng)常變化”的業(yè)務(wù)規(guī)則（位于Controller）和相對(duì)穩(wěn)定的業(yè)務(wù)邏輯（位于Model）分離開(kāi)，同時(shí)在Model層采用接口方式實(shí)現(xiàn)，以此來(lái)應(yīng)對(duì)將來(lái)不斷變化的業(yè)務(wù)需求。
新聞名稱(chēng)：從三層架構(gòu)到MVC-MVP
文章分享：http://www.dlmjj.cn/article/cdoccpd.html
