最近准備用Python做做網站，框架選了django，第一次接觸web框架，感覺很陌生，model view什么的很奇怪，不過了解了mvc這個模式之后好了很多，今天記錄下web中長見的幾種模式。
以下內容轉自：http://blog.csdn.net/hudan2714/article/details/50990359
MVC
MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典范，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件里面，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。
數據關系
- View 接受用戶交互請求
- View 將請求轉交給Controller
- Controller 操作Model進行數據更新
- 數據更新之后，Model通知View更新數據變化
- View 更新變化數據
方式
所有方式都是單向通信
結構實現
View ：使用 Composite模式
View和Controller：使用 Strategy模式
Model和 View：使用 Observer模式同步信息
使用
MVC中的View是可以直接訪問Model的！從而，View里會包含Model信息，不可避免的還要包括一些業務邏輯。在MVC模型里，更關注的Model的不變，而同時有多個對Model的不同顯示，及View。所以，在MVC模型里，Model不依賴於View，但是 View是依賴於Model的。不僅如此，因為有一些業務邏輯在View里實現了，導致要更改View也是比較困難的，至少那些業務邏輯是無法重用的。
MVP
mvp的全稱為Model-View-Presenter，Model提供數據，View負責顯示，Controller/Presenter負責邏輯的處理。MVP與MVC有着一個重大的區別：在MVP中View並不直接使用Model，它們之間的通信是通過Presenter (MVC中的Controller)來進行的，所有的交互都發生在Presenter內部，而在MVC中View會直接從Model中讀取數據而不是通過 Controller。
數據關系
- View 接收用戶交互請求
- View 將請求轉交給 Presenter
- Presenter 操作Model進行數據更新
- Model 通知Presenter數據發生變化
- Presenter 更新View數據
MVP的優勢
- Model與View完全分離，修改互不影響
- 更高效地使用，因為所有的邏輯交互都發生在一個地方—Presenter內部
- 一個Preseter可用於多個View，而不需要改變Presenter的邏輯（因為View的變化總是比Model的變化頻繁）。
- 更便於測試。把邏輯放在Presenter中，就可以脫離用戶接口來測試邏輯（單元測試）
方式
各部分之間都是雙向通信
結構實現
View ：使用 Composite模式
View和Presenter：使用 Mediator模式
Model和Presenter：使用 Command模式同步信息
MVC和MVP區別
MVP與MVC最大的一個區別就是：Model與View層之間倒底該不該通信（甚至雙向通信）
MVC和MVP關系
MVP：是MVC模式的變種。
項目開發中，UI是容易變化的，且是多樣的，一樣的數據會有N種顯示方式；業務邏輯也是比較容易變化的。為了使得應用具有較大的彈性，我們期望將UI、邏輯（UI的邏輯和業務邏輯）和數據隔離開來，而MVP是一個很好的選擇。
Presenter代替了Controller，它比Controller擔當更多的任務，也更加復雜。Presenter處理事件，執行相應的邏輯，這些邏輯映射到Model操作Model。那些處理UI如何工作的代碼基本上都位於Presenter。
MVC中的Model和View使用Observer模式進行溝通；MPV中的Presenter和View則使用Mediator模式進行通信；Presenter操作Model則使用Command模式來進行。基本設計和MVC相同：Model存儲數據，View對Model的表現，Presenter協調兩者之間的通信。在 MVP 中 View 接收到事件，然后會將它們傳遞到 Presenter, 如何具體處理這些事件，將由Presenter來完成。
如果要實現的UI比較復雜，而且相關的顯示邏輯還跟Model有關系，就可以在View和 Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View，避免兩者之間的關聯。而同時，因為Adapter實現了View的接口，從而可以保證與Presenter之 間接口的不變。這樣就可以保證View和Presenter之間接口的簡潔，又不失去UI的靈活性。
使用
MVP的實現會根據View的實現而有一些不同，一部分傾向於在View中放置簡單的邏輯，在Presenter放置復雜的邏輯；另一部分傾向於在presenter中放置全部的邏輯。這兩種分別被稱為：Passive View和Superivising Controller。
MVVM
MVVM是Model-View-ViewModel的簡寫。微軟的WPF帶來了新的技術體驗，如Silverlight、音頻、視頻、3D、動畫……，這導致了軟件UI層更加細節化、可定制化。同時，在技術層面，WPF也帶來了 諸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM（Model-View-ViewModel）框架的由來便是MVP（Model-View-Presenter）模式與WPF結合的應用方式時發展演變過來的一種新型架構框架。它立足於原有MVP框架並且把WPF的新特性糅合進去，以應對客戶日益復雜的需求變化。
數據關系
- View 接收用戶交互請求
- View 將請求轉交給ViewModel
- ViewModel 操作Model數據更新
- Model 更新完數據，通知ViewModel數據發生變化
- ViewModel 更新View數據
方式
雙向綁定。View/Model的變動，自動反映在 ViewModel，反之亦然。
使用
- 可以兼容你當下使用的 MVC/MVP 框架。
- 增加你的應用的可測試性。
- 配合一個綁定機制效果最好。
MVVM優點
MVVM模式和MVC模式一樣，主要目的是分離視圖（View）和模型（Model），有幾大優點:
1. 低耦合。View可以獨立於Model變化和修改，一個ViewModel可以綁定到不同的”View”上，當View變化的時候Model可以不變，當Model變化的時候View也可以不變。
2. 可重用性。你可以把一些視圖邏輯放在一個ViewModel里面，讓很多view重用這段視圖邏輯。
3. 獨立開發。開發人員可以專注於業務邏輯和數據的開發（ViewModel），設計人員可以專注於頁面設計，生成xml代碼。
4. 可測試。界面素來是比較難於測試的，而現在測試可以針對ViewModel來寫。
mvc,mvp,mvvm三者演化
再次聲明以上內容轉自：http://blog.csdn.net/hudan2714/article/details/50990359
對於django這個框架，近似於mvp，不過官方稱其為mtv，即 models,template,views
看下官方解釋：
Django appears to be a MVC framework, but you call the Controller the “view”, and the View the “template”. How come you don’t use the standard names?¶
Well, the standard names are debatable.
In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but whichdata is presented. The view describes which data you see, not how you see it. It’s a subtle distinction.
So, in our case, a “view” is the Python callback function for a particular URL, because that callback function describes which data is presented.
Furthermore, it’s sensible to separate content from presentation – which is where templates come in. In Django, a “view” describes which data is presented, but a view normally delegates to a template, which describes how the data is presented.
Where does the “controller” fit in, then? In Django’s case, it’s probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.
If you’re hungry for acronyms, you might say that Django is a “MTV” framework – that is, “model”, “template”, and “view.” That breakdown makes much more sense.
At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that’s most logical to us.
所以，django中，view 從template來，而controller則是由views.py 來處理邏輯，並返回界面。