事實上在 Java / JSP 常引用的網站開發架構中,還可分為 Model 1 與 Model 2。Model 1 還可分為二至三種,如下:
第一種是將 HTML 和 .NET (Java) code 混在一起,俗稱意大利麵式的寫法,如:ASP。這種 Inline code 最為人垢病的問題是程式可讀性低、難以維護。
第二種是由與 .aspx 一對一對應的 Code-Behind code 直接存取資料庫,亦即二層式的架構。但這樣的缺點是程式碼難以重複使用,且因為邏輯已經寫死在固定的頁面中,會造成系統日後擴充困難。
第 三種是經由自訂類別庫、App_Code 資料夾中的自訂類或軟體組件,去存取資料庫,或做商業邏輯的運算 (JSP + JavaBean)。但此種做法仍缺乏流程的統一控管,導致每一支 ASPX (JSP) 都要驗證使用者身份、驗證 request 的參數、處理 Session、做例外處理,甚至包括 View 裡的編碼原則、語系設定,都得在每一支 ASPX 對應的 Code-Behind 去處理,也因此不適合大型系統的開發、擴充和維護。這種架構雖然也能做到虛擬式的三層式或多層式架構,但也是目前 ASP.NET 2.0 的極限。
至 於 Model 2,即俗稱的 MVC Framework,則加入了 Controller 的部分,將流程及事件交由中心控管,除了可讓整個系統的運作流程更為明確,有效切開各層的工作,亦可避免讓 View 裡的 Code-Behind 去處理 Model 中的資料庫存取、商業邏輯運算,也不必再到處撰寫「流程傳遞和轉向」的程式碼,而改由中央的 Controller 程式碼 (action method) 來統一控管。
但 MVC 架構也有其缺點,例如開發人員需要另外花時間轉換觀念及學習 Framework,尤其是 .NET 的開發人員或團隊,因為過去較沒有 Controller 統一協調流程的觀念,勢必得重新習慣,將很多原本寫死在各個頁面中的程式碼,改寫進 Controller 裡面。而且系統在設計階段時,即要先協調好各個類別對象彼此間資料交換的格式及做法,因此勢必得拉長系統事先的分析、規劃時程。但若能有像 Struts 或 .NET MVC Framework 這樣現成的架構可套用,則日後開發大型系統時,即可望達到事半功倍的效果。
MVC優點:
1.大型開發的時候容易維護,擴充性很好。
2.能夠對HTML有完全的控制許可權,對於前端來說很友好。
3.能夠進行單元測試,保證功能的實現。
缺點:
1.沒有那麼多的現成控制項使用,開發效率相對較低(特別是對於菜鳥來說)
2.對於大型資料的處理比較難,還是因為沒有現成girdview控制項。這個控制項雖然產生的html結構異常複雜,但是對於處理大量而且複雜的資料來說是很不錯的。不過一般網站是很少有這種大量且複雜的資料,很多菜鳥都是用這個大炮來打蚊子,浪費且低效率。對於網站開發來說這個控制項應該不推薦使用。
剛學的菜鳥和在需要快速開發的情況下用webform就很好。
需要可擴充性,高度控制性情況下用MVC好。但是用這個架構門檻相對較高,如果你只懂asp.net 的webform開發形式的話,因為webform已經幫你做了太多的事情,換句話說你根本不知道真正的web開發是怎麼樣的。反而精通php,asp的人更容易上手。
MVC和webform開發各有各的用途。
但是你不應該使用asp.net mvc架構,如果符合下面幾條:
你對多態不是“非常”的熟悉
你不喜歡在這個架構上構建應用程式
你依賴於很多第三方的UI控制項
你不喜歡使用開源的程式
記者:您認為目前WEB企業級開發最大的障礙在哪一方面?如何運用ASP.NET MVC架構來減輕程式員在這一障礙上的壓力?
衣明志:以前曾經對我做過一次視頻採訪,那次我談到過這個這方面的一些內容,但是由於標題和部分表述的原因,可能被一些程式員誤解了我的意思。其實就像ASP.NET MVC 2相對於ASP.NET MVC 1.0來說,做了這麼多的改進,改進的目標是什麼呢?很大程度上就是減少不必要的勞動量和潛在風險,提高生產力,讓開發人員的精力更多放到業務處理方面(我提到的業務均不是市場人員所說的業務)。所以Web的企業級開發往往最大的障礙是開發人員把太多精力浪費在了非業務核心的方面,比如說資料驗證、UI 代碼的編寫和一些繁瑣但沒什麼技術含量的工作方面。
新版的ASP.NET MVC的很多新特性都減輕了開發人員不少的工作壓力,比如說Html.EditForModel方法,可以直接在View中產生很不錯的編輯介面,而且有自動識別能力:bool型的屬性,對應的自動產生CheckBox;枚舉類型自動產生下拉式清單等等。而Controller、Action、Filter 等都給我們帶來很多類似的自動機制,減少了很多繁瑣無味的工作,使我們可以把更多精力放到核心工作方面去。
通過對MVC的學習,我們可以看到MVC有如下特點:
1) 業務處理與顯示分離:ASPX頁面與CS代碼徹底分離。更好的複用和維護。
2) 伺服器端的表單控制項不再被提倡使用,取而代之使用傳統的input,或直接讓Html.TextBox產生控制項標籤。
3) 沒有了事件驅動模型。在ASP.NET MVC中,當某個按鈕被點擊,你不要再習慣性想到應該在相應的aspx.cs中有個Click處理方法,你應該想到的是該有某個Controller中有個Action來處理這個事件。
4) 沒有了資料繫結。如果你習慣了GridView的資料繫結,在ASP.NET MVC中則需要改變思路,你自己動手解決。
5) 增加了地址修正。MVC的Routing組件讓我們可以很好的進行URL路由處理。
6) 總體來看,可以理解MVC是基於Web Form的一種編程方式模型擴充,是一種展示層的編程模型方案。
MVC工作的優點是顯然的,更加有利於理解分層邏輯,把握代碼的層次感。Controller到aspx頁面之間的過程,已經被架構隔離。至於 Controller或者View頁面與Model調用的過程,還是需要自己來把握。ASP.NET的MVC架構實現了Controller代碼的單獨管理。
而看WebForm開發模型,則只在HttpHandler容器中執行,對其進行分層,在大的方面缺乏支援,而只能依靠邏輯上分離。並不是不能分離,而是由一定的局限性。HttpHandler的攔截,是跟訪問尾碼名有關的。當請求一個頁面時,那就是一個Handler,而 WebForm模型實現顯示與邏輯分離,才有的是WinForm的事件驅動。
顯然,事件必須被註冊到頁面裡,比如 Button1_Click這樣的代碼。而在Button1_Click執行之前,Page_Load方法會被執行。顯示代碼被寫入Page_Load方 法中,那麼就會造成需要寫額外的廢代碼,比如if (!Page.IsPostBack)這樣的判定。而在Button1_Click執行後需要顯示的部分,則比較難處理,寫出另一個方法,也是必須要在 Button1_Click裡調用的。替代的解決方案是使用Response.Redirect,在一個aspx頁面中處理邏輯,處理完就跳轉到另外一個 顯示的頁面。這樣做的壞處是,在兩個頁面中資料很難共用,而跳轉是通過標記302來實現,因此多一次請求。
而另外還可以通過 Server.Execute,Server.Transfer或者Context.RewritePath這樣的處理方式,則兩個頁面轉換是在伺服器端 完成,可以共用資料,可以說和MVC架構的處理方式大同小異,缺點是需要手動設定這些重新定向的屬性。
從以上分析可以看出,MVC架構 具有很強的優越性,而WebForm也不是一無是處,在簡單的應用中更加容易開發。WebForm也是可以實現和MVC一樣的分層方式,只是處理時需要多 寫一些代碼而已。而我認為,在用WebForm開發分層遇到的最大問題是頁面與頁面之間資料的傳遞問題,而掌握好WebForm中使用伺服器端跳轉的應用技巧(Server.Execute,Server.Transfer或者Context.RewritePath)進行開發就可以解決資料轉送問題,用 WebForm開發比MVC架構更容易理解,不會產生複雜的配置,也是一個很不錯的選擇。