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