淺談MVC

淺談MVC

What is MVC?

　　MVC與模板概念的理解：MVC(Model View Controller)模型－視圖－控制器

 

　　MVC原本是存在於Desktop程序中的，M是指數據模型，V是指用戶界面，C則是控制器。使用MVC 的目的是將M和V的實現代碼分離，從而使同一個程序可使用不一樣的表現形式。好比一批統計數據你能夠分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步，一旦M改變，V應該同步更新。

 

　　模型－視圖－控制器（MVC）是Xerox PARC在八十年代爲編程語言Smalltalk－80發明的一種軟件設計模式，至今已被普遍使用。最近幾年被推薦爲Oracle旗下Sun公司Java EE平臺的設計模式，而且受到愈來愈多的使用 ColdFusion 和 PHP 的開發者的歡迎。模型－視圖－控制器模式是一個有用的工具箱，它有不少好處，但也有一些缺點。

 

MVC如何工做　　

MVC是一個設計模式，它強制性的使應用程序的輸入、處理和輸出分開。使用MVC應用程序被分紅三個核心部件：模型、視圖、控制器。它們各自處理本身的任務。

 

視圖

　　視圖是用戶看到並與之交互的界面。對老式的Web應用程序來講，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演着重要的角色，但一些新的技術已層出不窮，它們包括Macromedia Flash和像XHTML，XML/XSL，WML等一些標識語言和Web services.

 

　　如何處理應用程序的界面變得愈來愈有挑戰性。MVC一個大的好處是它能爲你的應用程序處理不少不一樣的視圖。在視圖中其實沒有真正的處理髮生，無論這些數據是聯機存儲的仍是一個僱員列表，做爲視圖來說，它只是做爲一種輸出數據並容許用戶操縱的方式。

 

模型

　　模型表示企業數據和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。例如它可能用像EJB和ColdFusion Component這樣的構件對象來處理數據庫。被模型返回的數據是中立的，就是說模型與數據格式無關，這樣一個模型能爲多個視圖提供數據。因爲應用於模型的代碼只需寫一次就能夠被多個視圖重用，因此減小了代碼的重複性。

 

控制器

　　控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求。因此當單擊Web頁面中的超連接和發送HTML表單時，控制器自己不輸出任何東西和作任何處理。它只是接收請求並決定調用哪一個模型構件去處理請求，而後再肯定用哪一個視圖來顯示返回的數據。

 

Why MVC?

　　大部分Web應用程序都是用像ASP，PHP，或者CFML這樣的過程化(自PHP5.0版本後已全面支持面向對象模型)語言來建立的。它們將像數據庫查詢語句這樣的數據層代碼和像HTML這樣的表示層代碼混在一塊兒。經驗比較豐富的開發者會將數據從表示層分離開來，但這一般不是很容易作到的，它須要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。儘管構造MVC應用程序須要一些額外的工做，可是它給咱們帶來的好處是毋庸置疑的。

 

　　首先，最重要的一點是多個視圖能共享一個模型，如今須要用愈來愈多的方式來訪問你的應用程序。對此，其中一個解決之道是使用MVC，不管你的用戶想要Flash界面或是 WAP 界面；用一個模型就能處理它們。因爲你已經將數據和業務規則從表示層分開，因此你能夠最大化的重用你的代碼了。

 

　　因爲模型返回的數據沒有進行格式化，因此一樣的構件能被不一樣界面使用。例如，不少數據可能用HTML來表示，可是它們也有可能要用Adobe Flash和WAP來表示。模型也有狀態管理和數據持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。

 

　　由於模型是自包含的，而且與控制器和視圖相分離，因此很容易改變你的應用程序的數據層和業務規則。若是你想把你的數據庫從MySQL移植到Oracle，或者改變你的基於RDBMS數據源到LDAP，只需改變你的模型便可。一旦你正確的實現了模型，無論你的數據來自數據庫或是LDAP服務器，視圖將會正確的顯示它們。因爲運用MVC的應用程序的三個部件是相互獨立，改變其中一個不會影響其它兩個，因此依據這種設計思想你能構造良好的鬆耦合的構件。

 

　　對我來講，控制器也提供了一個好處，就是可使用控制器來聯接不一樣的模型和視圖去完成用戶的需求，這樣控制器能夠爲構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器能夠根據用戶的需求選擇模型進行處理，而後選擇視圖將處理結果顯示給用戶。

 

MVC的優勢

低耦合性

　　視圖層和業務層分離，這樣就容許更改視圖層代碼而不用從新編譯模型和控制器代碼，一樣，一個應用的業務流程或者業務規則的改變只須要改動MVC的模型層便可。由於模型與控制器和視圖相分離，因此很容易改變應用程序的數據層和業務規則。

高可用性和適用性

　　隨着技術的不斷進步，如今須要用愈來愈多的方式來訪問應用程序。MVC模式容許你使用各類不一樣樣式的視圖來訪問同一個服務器端的代碼。它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），好比，用戶能夠經過電腦也可經過手機來訂購某樣產品，雖然訂購的方式不同，但處理訂購產品的方式是同樣的。因爲模型返回的數據沒有進行格式化，因此一樣的構件能被不一樣的界面使用。例如，不少數據可能用HTML來表示，可是也有可能用WAP來表示，而這些表示所須要的命令是改變視圖層的實現方式，而控制層和模型層無需作任何改變。

較低的生命週期成本

　　MVC使下降開發和維護用戶接口的技術含量成爲可能。

快速的部署

　　使用MVC模式使開發時間獲得至關大的縮減，它使程序員（Java開發人員）集中精力於業務邏輯，界面程序員（HTML和JSP開發人員）集中精力於表現形式上。

可維護性

　　分離視圖層和業務邏輯層也使得WEB應用更易於維護和修改。

有利於軟件工程化管理

　　因爲不一樣的層各司其職，每一層不一樣的應用具備某些相同的特徵，有利於經過工程化、工具化管理程序代碼。

 

MVC的缺點

　　MVC的缺點是因爲它沒有明確的定義，因此徹底理解MVC並非很容易。使用MVC須要精心的計劃，因爲它的內部原理比較複雜，因此須要花費一些時間去思考。

 

　　你將不得不花費至關可觀的時間去考慮如何將MVC運用到你的應用程序，同時因爲模型和視圖要嚴格的分離，這樣也給調試應用程序帶來了必定的困難。每一個構件在使用以前都須要通過完全的測試。一旦你的構件通過了測試，你就能夠毫無顧忌的重用它們了。

 

　　根據開發者經驗，因爲開發者將一個應用程序分紅了三個部件，因此使用MVC同時也意味着你將要管理比之前更多的文件，這一點是顯而易見的。這樣好像咱們的工做量增長了，可是請記住這比起它所能帶給咱們的好處是不值一提。

 

　　MVC並不適合小型甚至中等規模的應用程序，花費大量時間將MVC應用到規模並非很大的應用程序一般會得不償失。

 

　　MVC設計模式是一個很好建立軟件的途徑，它所提倡的一些原則，像內容和顯示互相分離可能比較好理解。可是若是你要隔離模型、視圖和控制器的構件，你可能須要從新思考你的應用程序，尤爲是應用程序的構架方面。若是你肯接受MVC，而且有能力應付它所帶來的額外的工做和複雜性，MVC將會使你的軟件在健壯性，代碼重用和結構方面上一個新的臺階。