Unity3dMVC架構程式設計核心思想

MVC元件類型的關系和功能

MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟體設計典範，用一種業務邏輯、資料、界面 顯示分離的方法組織代碼，将業務邏輯聚集到一個部件裡面，在改進和個性化定制界面及使用者互動的同時，不需要重新編寫業務邏輯。MVC被獨特的發展起來用于 映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化使用者界面的結構中。

簡介

編輯

MVC開始是存在于桌面程式中的，M是指業務模型，V是指

使用者界面

，C則是控制器，使用MVC的目的是将M和V的實作代碼分離，進而使同一個程式可以使用不同的表現形式。比如一批統計資料可以分别用

柱狀圖

、

餅圖

來表示。C存在的目的則是確定M和V的同步，一旦M改變，V應該同步更新。[1-2]

模型－視圖－控制器（

MVC

）是

Xerox PARC

在二十世紀八十年代為程式設計語言Smalltalk－80發明的一種

軟體設計模式

，已被廣泛使用。後來被推薦為

Oracle

旗下

Sun

公司

Java EE

平台的設計模式，并且受到越來越多的使用

ColdFusion

和

PHP

的開發者的歡迎。模型－視圖－控制器模式是一個有用的

工具箱

，它有很多好處，但也有一些缺點。[3]

MVC 程式設計模式

MVC 是一種使用 MVC（Model View Controller 模型-視圖-控制器）設計建立 Web 應用程式的模式：[1]

Model（模型）表示應用程式核心（比如資料庫記錄清單）。

View（視圖）顯示資料（資料庫記錄）。

Controller（控制器）處理輸入（寫入資料庫記錄）。

MVC 模式同時提供了對 HTML、CSS 和 JavaScript 的完全控制。

Model（模型）是應用程式中用于處理應用程式資料邏輯的部分。　　通常模型對象負責在資料庫中存取資料。

View（視圖）是應用程式中處理資料顯示的部分。　　通常視圖是依據模型資料建立的。

Controller（控制器）是應用程式中處理使用者互動的部分。　　通常控制器負責從視圖讀取資料，控制使用者輸入，并向模型發送資料。

MVC 分層有助于管理複雜的應用程式，因為您可以在一個時間内專門關注一個方面。例如，您可以在不依賴業務邏輯的情況下專注于視圖設計。同時也讓應用程式的測試更加容易。

MVC 分層同時也簡化了分組開發。不同的開發人員可同時開發視圖、控制器邏輯和業務邏輯。

視圖

視圖是使用者看到并與之互動的界面。對老式的Web應用程式來說，視圖就是由

HTML

元素組成的界面，在新式的Web應用程式中，

HTM

L依舊在視圖中扮演着重要的角色，但一些新的技術已層出不窮，它們包括

Adobe Flash

和像

XHTML

，

XML

/

XSL

,

WML

等一些辨別語言和

Web services

.

MVC好處是它能為應用程式處理很多不同的

。在視圖中其實沒有真正的處理發生，不管這些資料是聯機存儲的還是一個雇員清單，作為視圖來講，它隻是作為一種輸出資料并允許使用者操縱的方式。[6]

模型

模型表示企業資料和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。例如它可能用像

EJB

s和ColdFusion Components這樣的構件對象來處理資料庫，被模型傳回的資料是中立的，就是說模型與資料格式無關，這樣一個模型能為多個視圖提供資料，由于應用于模型的代碼隻需寫一次就可以被多個視圖重用，是以減少了代碼的重複性。[6]

控制器

控制器接受使用者的輸入并調用模型和視圖去完成使用者的需求，是以當單擊Web頁面中的超連結和發送

HTML表單

時，控制器本身不輸出任何東西和做任何處理。它隻是接收請求并決定調用哪個模型構件去處理請求，然後再确定用哪個視圖來顯示傳回的資料。[6]

特點

優點

耦合性

低

視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變隻需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，是以很容易改變應用程式的資料層和業務規則。

模型是自包含的，并且與控制器和視圖相分離，是以很容易改變應用程式的資料層和業務規則。如果把資料庫從MySQL移植到

，或者改變基于RDBMS資料源到

LDAP

，隻需改變模型即可。一旦正确的實作了模型，不管資料來自資料庫或是LDAP伺服器，視圖将會正确的顯示它們。由于運用MVC的應用程式的三個部件是互相獨立，改變其中一個不會影響其它兩個，是以依據這種設計思想能構造良好的

松耦合

的構件。[11]

重用性高

随着技術的不斷進步，需要用越來越多的方式來通路應用程式。

MVC模式

允 許使用各種不同樣式的視圖來通路同一個伺服器端的代碼，因為多個視圖能共享一個模型，它包括任何WEB（HTTP）浏覽器或者無線浏覽器（wap），比 如，使用者可以通過電腦也可通過手機來訂購某樣産品，雖然訂購的方式不一樣，但處理訂購産品的方式是一樣的。由于模型傳回的資料沒有進行格式化，是以同樣的 構件能被不同的界面使用。例如，很多資料可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的指令是改變視圖層的實作方式，而控制層和 模型層無需做任何改變。由于已經将資料和業務規則從表示層分開，是以可以最大化的重用代碼了。模型也有狀态管理和資料持久性處理的功能，例如，基于會話的 購物車和電子商務過程也能被Flash網站或者無線聯網的應用程式所重用。[11]

生命周期

成本低

MVC使開發和維護使用者

接口

的技術含量降低。

部署快

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

可維護性高

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

有利軟體工程化管理

由于不同的層各司其職，每一層不同的應用具有某些相同的特征，有利于通過 工程化、工具化管理程式代碼。控制器也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成使用者的需求，這樣控制器可以為構造應用程式提供強 有力的手段。給定一些可重用的模型和視圖，控制器可以根據使用者的需求選擇模型進行處理，然後選擇視圖将處理結果顯示給使用者。[12-13]

缺點

沒有明确的定義

完全了解MVC并不是很容易。使用MVC需要精心的計劃，由于它的内部原理比較複雜，是以需要花費一些時間去思考。同時由于模型和視圖要嚴格的分離，這樣也給調試應用程式帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。

不适合小型，中等規模的應用程式

花費大量時間将MVC應用到規模并不是很大的應用程式通常會得不償失。

增加系統結構和實作的複雜性

對于簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的複雜性，并可能産生過多的更新操作，降低運作效率。

視圖與控制器間的過于緊密的連接配接

視圖與控制器是互相分離，但卻是聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。

視圖對模型資料的低效率通路

依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示資料。對未變化資料的不必要的頻繁通路，也将損害操作性能。

一般進階的界面工具或構造器不支援模式

改造這些工具以适應MVC需要和建立分離的部件的代價是很高的，會造成MVC使用的困難。