何謂MVC模式
MVC模式（Model-View-Controller）是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。
MVC模式最早由Trygve Reenskaug在1978年提出[1] ，是全錄帕羅奧多研究中心（Xerox PARC）在20世紀80年代為程式語言Smalltalk發明的一種軟體架構。MVC模式的目的是實作一種動態的程式設計，使後續對程式的修改和擴充功能簡化，並且使程式某一部分的重複利用成為可能。除此之外，此模式通過對複雜度的簡化，使程式結構更加直覺。軟體系統通過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。專業人員可以通過自身的專長分組：
（控制器 Controller）- 負責轉發請求，對請求進行處理。
（視圖 View） - 介面設計人員進行圖形介面設計。
（模型 Model） - 程式設計師編寫程式應有的功能（實作演算法等等）、資料庫專家進行資料管理和資料庫設計(可以實作具體的功能)。
元件的互動
MVC元件之間的典型合作
除了將應用程式劃分為三種元件，模型 - 視圖 - 控制器（MVC）設計定義它們之間的相互作用。[2]
模型（Model） 用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。「 Model 」有對資料直接存取的權力，例如對資料庫的存取。「Model」不依賴「View」和「Controller」，也就是說， Model 不關心它會被如何顯示或是如何被操作。但是 Model 中資料的變化一般會通過一種重新整理機制被公布。為了實作這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式））
視圖（View）能夠實作資料有目的的顯示（理論上，這不是必需的）。在 View 中一般沒有程式上的邏輯。為了實作 View 上的重新整理功能，View 需要存取它監視的資料模型（Model），因此應該事先在被它監視的資料那裡註冊。
控制器（Controller）起到不同層面間的組織作用，用於控制應用程式的流程。它處理事件並作出響應。「事件」包括使用者的行為和資料 Model 上的改變。
優點
在最初的JSP網頁中，像資料庫查詢語句(SQL query)這樣的資料層代碼和像HTML這樣的表示層代碼是混在一起。雖然有著經驗比較豐富的開發者會將資料從表示層分離開來，但這樣的良好設計通常並不是很容易做到的，實作它需要精心地計劃和不斷的嘗試。MVC可以從根本上強制性地將它們分開。儘管構造MVC應用程式需要一些額外的工作，但是它帶給我們的好處是毋庸置疑的。
首先，多個 View 能共享一個 Model 。如今，同一個Web應用程式會提供多種使用者介面，例如使用者希望既能夠通過瀏覽器來收發電子信件，還希望通過手機來存取電子信箱，這就要求Web網站同時能提供Internet介面和WAP介面。在MVC設計模式中， Model 響應使用者請求並返迴響應資料，View 負責格式化資料並把它們呈現給使用者，業務邏輯和表示層分離，同一個 Model 可以被不同的 View 重用，所以大大提高了代碼的可重用性。
其次，Controller 是自包含（self-contained）指高獨立內聚的物件，與 Model 和 View 保持相對獨立，所以可以方便的改變應用程式的資料層和業務規則。例如，把資料庫從MySQL移植到Oracle，或者把RDBMS資料來源改變成LDAP資料來源，只需改變 Model 即可。一旦正確地實作了控制器，不管資料來自資料庫還是LDAP伺服器，View 都會正確地顯示它們。由於MVC模式的三個模組相互獨立，改變其中一個不會影響其他兩個，所以依據這種設計思想能構造良好的少互擾性的構件。
此外，Controller 提高了應用程式的靈活性和可配置性。Controller 可以用來連線不同的 Model 和 View 去完成使用者的需求，也可以構造應用程式提供強有力的手段。給定一些可重用的 Model 、 View 和Controller 可以根據使用者的需求選擇適當的 Model 進行處理，然後選擇適當的的 View 將處理結果顯示給使用者。
評價及適用範圍
MVC模式的缺點是由於它沒有明確的定義，所以完全理解MVC模式並不是很容易。使用MVC模式需要精心的計劃，由於它的內部原理比較複雜，所以需要花費一些時間去思考。開發一個MVC模式架構的工程，將不得不花費相當可觀的時間去考慮如何將MVC模式運用到應用程式中，同時由於Model和 View 要嚴格的分離，這樣也給偵錯應用程式帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。另外由於MVC模式將一個應用程式分成了三個部件，所以這意味著同一個工程將包含比以前更多的檔案。
過去MVC模式並不適合小型甚至中等規模的應用程式，這樣會帶來額外的工作量，增加應用的複雜性。但現在多數軟體設計框架，能直接快速提供MVC骨架，供中小型應用程式開發，此問題不再存在。對於開發存在大量使用者介面，並且邏輯複雜的大型應用程式，MVC將會使軟體在健壯性、代碼重用和結構方面上一個新的台階。儘管在最初構建MVC模式框架時會花費一定的工作量，但從長遠的角度來看，它會大大提高後期軟體開發的效率。
資料來源：維基百科
MVC模式最早由Trygve Reenskaug在1978年提出[1] ，是全錄帕羅奧多研究中心（Xerox PARC）在20世紀80年代為程式語言Smalltalk發明的一種軟體架構。MVC模式的目的是實作一種動態的程式設計，使後續對程式的修改和擴充功能簡化，並且使程式某一部分的重複利用成為可能。除此之外，此模式通過對複雜度的簡化，使程式結構更加直覺。軟體系統通過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。專業人員可以通過自身的專長分組：
（控制器 Controller）- 負責轉發請求，對請求進行處理。
（視圖 View） - 介面設計人員進行圖形介面設計。
（模型 Model） - 程式設計師編寫程式應有的功能（實作演算法等等）、資料庫專家進行資料管理和資料庫設計(可以實作具體的功能)。
元件的互動
MVC元件之間的典型合作
除了將應用程式劃分為三種元件，模型 - 視圖 - 控制器（MVC）設計定義它們之間的相互作用。[2]
模型（Model） 用於封裝與應用程式的業務邏輯相關的資料以及對資料的處理方法。「 Model 」有對資料直接存取的權力，例如對資料庫的存取。「Model」不依賴「View」和「Controller」，也就是說， Model 不關心它會被如何顯示或是如何被操作。但是 Model 中資料的變化一般會通過一種重新整理機制被公布。為了實作這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 可以了解在資料 Model 上發生的改變。（比較：觀察者模式（軟體設計模式））
視圖（View）能夠實作資料有目的的顯示（理論上，這不是必需的）。在 View 中一般沒有程式上的邏輯。為了實作 View 上的重新整理功能，View 需要存取它監視的資料模型（Model），因此應該事先在被它監視的資料那裡註冊。
控制器（Controller）起到不同層面間的組織作用，用於控制應用程式的流程。它處理事件並作出響應。「事件」包括使用者的行為和資料 Model 上的改變。
優點
在最初的JSP網頁中，像資料庫查詢語句(SQL query)這樣的資料層代碼和像HTML這樣的表示層代碼是混在一起。雖然有著經驗比較豐富的開發者會將資料從表示層分離開來，但這樣的良好設計通常並不是很容易做到的，實作它需要精心地計劃和不斷的嘗試。MVC可以從根本上強制性地將它們分開。儘管構造MVC應用程式需要一些額外的工作，但是它帶給我們的好處是毋庸置疑的。
首先，多個 View 能共享一個 Model 。如今，同一個Web應用程式會提供多種使用者介面，例如使用者希望既能夠通過瀏覽器來收發電子信件，還希望通過手機來存取電子信箱，這就要求Web網站同時能提供Internet介面和WAP介面。在MVC設計模式中， Model 響應使用者請求並返迴響應資料，View 負責格式化資料並把它們呈現給使用者，業務邏輯和表示層分離，同一個 Model 可以被不同的 View 重用，所以大大提高了代碼的可重用性。
其次，Controller 是自包含（self-contained）指高獨立內聚的物件，與 Model 和 View 保持相對獨立，所以可以方便的改變應用程式的資料層和業務規則。例如，把資料庫從MySQL移植到Oracle，或者把RDBMS資料來源改變成LDAP資料來源，只需改變 Model 即可。一旦正確地實作了控制器，不管資料來自資料庫還是LDAP伺服器，View 都會正確地顯示它們。由於MVC模式的三個模組相互獨立，改變其中一個不會影響其他兩個，所以依據這種設計思想能構造良好的少互擾性的構件。
此外，Controller 提高了應用程式的靈活性和可配置性。Controller 可以用來連線不同的 Model 和 View 去完成使用者的需求，也可以構造應用程式提供強有力的手段。給定一些可重用的 Model 、 View 和Controller 可以根據使用者的需求選擇適當的 Model 進行處理，然後選擇適當的的 View 將處理結果顯示給使用者。
評價及適用範圍
MVC模式的缺點是由於它沒有明確的定義，所以完全理解MVC模式並不是很容易。使用MVC模式需要精心的計劃，由於它的內部原理比較複雜，所以需要花費一些時間去思考。開發一個MVC模式架構的工程，將不得不花費相當可觀的時間去考慮如何將MVC模式運用到應用程式中，同時由於Model和 View 要嚴格的分離，這樣也給偵錯應用程式帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。另外由於MVC模式將一個應用程式分成了三個部件，所以這意味著同一個工程將包含比以前更多的檔案。
過去MVC模式並不適合小型甚至中等規模的應用程式，這樣會帶來額外的工作量，增加應用的複雜性。但現在多數軟體設計框架，能直接快速提供MVC骨架，供中小型應用程式開發，此問題不再存在。對於開發存在大量使用者介面，並且邏輯複雜的大型應用程式，MVC將會使軟體在健壯性、代碼重用和結構方面上一個新的台階。儘管在最初構建MVC模式框架時會花費一定的工作量，但從長遠的角度來看，它會大大提高後期軟體開發的效率。
資料來源：維基百科
留言
張貼留言