|
|
我們總會有這樣一個經驗：一個系統最不容易也最不應該變化的部分是領域邏輯，最容易變化也最應該變化的是數據的呈現方式。
在Java的各種應用中可以說是到處可見mvc，j2ee貫穿mvc的概念，Android的開發方式也是類mvc的，mvc結構對于做過Java應用的人而言簡直就是司空見慣。而在.NET這邊，由于之前微軟為大家提供的各種winform、ASP.NET項目典范（比如那個petshop series）將“三層”概念很好的灌輸到了.NET程序員的大腦中，許多.NET開發者凡是做個東西都要搬出自己最拿手的IModel、IDAL這樣的神器。
其實mvc與所謂的“三層架構”是兩個層次上的東西，前者是一種結構模式，而后者則是分層的角度去說。
一件很奇怪的事情，許多人知道“三層”卻不知道mvc，其實這要歸結與.NET的早期開發技術ASP.NET和winform這些page controller的典范讓許多人對三層夸夸其談卻對mvc視而不見甚至一無所知。什么是page controller模式呢？搞.NET的大多都用過winform和webform，這種xxxform用起來很直觀，我們想要做一個程序，ok，最簡單的方式就是拖拖拽拽幾個控件，然后在一個叫code behind的東西里寫這些UI事件的處理邏輯，加一大堆變量用于記錄數據和狀態，這樣一個程序就能出爐。這種開發方式對于一些小軟件系統的開發其實效率還是蠻高的，后來人們看到其弊端---一旦修改UI，事件處理就要跟著變，但是業務還是那個業務，憑什么要修改非UI的代碼？于是有人提出“三層”，最樸素的理解就是將原本那堆事件處理里的code分成業務代碼和數據庫訪問代碼并轉移到其它類中，做多了就把那坨UI叫做UI，那坨業務代碼叫做BLL，那坨DAO叫做DAL。也就是這種架構：
而對于j2ee的開發者來說熟悉的是下圖。
MVC是什么
MVC是一個很經典的結構，并且其又其思想衍生出很多變種比如MVP,MVVP。傳統的MVC結構之一是這樣的（拿主動型mvc來說）：
比如web開發（比如ASP.NET mvc或者是Java的web開發方式）,view就是純web頁面或者webservice，當提交一個表單/調用webservice或者ajax后會將數據提交給controller（當然期間可能會經過各種filterchain、listener這樣的東西）controller調用相應的業務模塊來處理這個請求，最終結果會更新View的顯示。
MVP
對于非天然mvc的框架
對于ASP.NET/winform而言，雖然可以通過改造讓其支持mvc結構的開發（比如通過定制IHttpModule、IHttpHandler云云），但是在企業看來這些都算是邪門武功（因為這樣會喪失xxxform在開發上的很多特性比如快速開發）。大多數使用的是mvp模式。什么是mvp呢？其實mvp是mvc的一個變種。因為用winform或者webform的話form始終是個阻礙mvc開發的問題。那么好，我們仍然使用designer和codebehind，其實一個架構設計的好壞是取決于人而不是具體的技術的，只要我們OO一時強page controller一樣好用。
在MVP模式中我們需要自己定制各個View（web頁面或者窗體）對應的IView和IPresenter、IModel。IView要對IPresenter暴露操作UI、數據綁定的接口，IPresenter對IView要暴露當UI事件觸發需要調用的接口，IPresenter根據IView傳遞過來的請求調用業務接口并根據結果操作UI。舉個簡單的例子，一個計算“x+y=?”的程序。如果我們這樣定義IPresenter和IView
public interface IPresenter
{
IView View { get; set; }
void CalculateResult();
}
public interface IView
{
IPresenter Presenter { get; set; }
void ShowResult(string result);
int ValueOne { get; }
int ValueTwo { get; }
}
NET技術：談.net開發人員應該熟悉的開發模式，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
