ASP.NET MVC 常見問題解答 Part 1

從上次 徵求 ASP.NET MVC 常見問題與書籍內容建議 之後已經累積了不少人對於 ASP.NET MVC 的問題與疑慮,所以藉此批次回應各位的問題,希望讓 ASP.NET MVC 這個明日之星能夠得到越來越多人的重視,而且希望能讓大家相信 ASP.NET MVC 絕對是個優質 Web 開發架構,應該義無反顧的擁抱它。

其實從 ASP.NET MVC 1.0 面市之後,已經有不少優質的英文書籍出現,網路上學習資源也不少,若英文還不錯的人應該很輕易就可以透過自修學成。我目前正在著手撰寫 ASP.NET MVC 2.0 的中文書籍,預計明年 3 ~ 4 月會出版,不好意思讓大家久等了,敬請拭目以待。

 

常見問題解答

1. ASP.NET MVC 與傳統 ASP.NET Web Form 開發有什麼不同?

ASP.NET Web Form 已經是 10 年前面市的技術了,走了那麼久的時間,大家也慢慢的看到許多當初沒想到的地方,雖然 ASP.NET Web Form 的元件化技術已經非常成熟,但利用 Web Form 開發 Web 應用程式還是會遇到許多瓶頸與限制,幾乎所有 ASP.NET 開發人員都會遇到這些惱人的問題,例如:

  • 邪惡的 ViewState ( 用了像 GridView 這種超大控制項非常容易失控 )
  • 控制項元件對 HTML 控制不夠直覺或太過複雜 ( 有網友說: 控制項很難控制 )
  • 不容易採用 TDD ( 測試導向開發模式 ) 開發、也不容易撰寫單元測試

許多 ASP.NET 開發人員對 MVC 設計樣式非常陌生,而且 ASP.NET MVC 是一個今年才正式面市的全新技術,一個又新、又陌生的技術相信會讓許多人望之卻步,不過還是希望各位能以理性的態度看待一個全新的技術,以下是 ASP.NET MVC 擁有比 ASP.NET Web Form 還多優勢的地方:

  • 清楚的 關注點分離(Separation of Concerns; SoC) 強迫你寫出較 Web Form 還更易於維護的程式
  • 開放特性 (完全開放原始碼) 與 社群支持 (目前國外社群非常活躍)
  • 可讓你完全控制 HTTP 輸出內容 ( 比 Web Form 好太多太多了 )
  • 優秀的開發效率 (這也是一般人的疑慮,以下會有回應)
  • 易於測試的架構
  • 易於分工的架構

ASP.NET MVC 目前的缺點是:

  • 缺法工具支援 ( 不像 Web Form 可讓你不懂 HTML, CSS, JavaScript 也能開發網站 )
  • 缺法成熟的元件化技術支援 ( Server Control v.s. HTML Helper )

推薦延伸閱讀

 

2. 採用 ASP.NET MVC 技術必須捨棄傳統 ASP.NET Web Form 哪些東西?

其實相差不多,把 ASP.NET Page Framework 提供的功能去掉,再加上 ASP.NET MVC 新增的一些東西,就等於 ASP.NET MVC 了,其中包括:

除此之外,其他現有的 ASP.NET 技術都可以繼續使用,而且也完全沒改變!例如:ASP.NET Application Life Cycle, ASP.NET Provider Model (Membership, Profile, SiteMap, …), Web Caching, Session, Authentication, … 等等

 

3. 什麼情況適用 ASP.NET MVC 什麼情況適用 ASP.NET Web Form?

我有幾個非常主觀的看法,供大家參考:

  • 小網站適合用 ASP.NET Web Form,大網站適合用 ASP.NET MVC
  • 參與開發人數少的網站用 ASP.NET Web Form,參與開發人數多的網站用 ASP.NET MVC
  • 擁有大量現有 Web Form 程式的人建議繼續使用 ASP.NET Web Form
  • 全新開發的網站建議採用 ASP.NET MVC

 

4. ASP.NET MVC 是否速度上會比 ASP.NET Web Form 慢?

關於「速度」有幾個層面可說:

  • 開發速度 / 開發效率
    • 由於 ASP.NET MVC 是新技術,剛開始一定比你熟悉的 Web Form 開發速度慢
    • 採用 ASP.NET MVC 開發一段時間後,絕對比 Web Form 開發速度快,而且可維護性會比 Web Form 好非常多。
  • 執行速度
    • WebForm 的龐大 Page Framework 所耗用的 CPU 指令集絕對比 ASP.NET MVC 多很多,如果單就這點來看,ASP.NET MVC 絕對勝出!
    • 事事無絕對,優秀的 ASP.NET Web Form 開發人員寫出來的 Code 還是可能比資淺的 ASP.NET MVC 開發人員寫的 Code 來的快!

 

5. 關於 ASP.NET MVC 的 M、V、C 真的可以各自獨立開發嗎?是否會有所限制?

可以,但沒那麼絕對!完全獨立開發雖然可行,但你如果真的這麼做就會綁手綁腳的,而且失去工具支援,我指的「完全獨立開發」是指專案一開始就讓 M、V、C 獨立開發,沒什麼必要,但是可行。

M、V、C 的關係是既分工又合作,必須有點黏又不能太黏的情況下,才能發揮 ASP.NET MVC 的優勢。

依照我這半年多來的實務開發經驗,我覺得 M ( Model ) 是 MVC 架構的中心,先有 Model 之後,就可以讓 Controller 與 View 參考這些 Model (模型),並且進行分工開發,最後在進行整合即可,這是我認為最有效率的開發方法。

 

6. 現有的 ASP.NET Web Form 專案是否可以逐步轉移至 ASP.NET MVC 專案?

嚴格一點來說:沒辦法,必須重新來過、打掉重練!

輕鬆一點來說:可以,你可以將現有的 Web Form 程式跟 Data Access Layer (DAL) 的部分與 ASP.NET MVC 的 Model 共用,各頁面 Code Behind 的部分慢慢抽離至 ASP.NET MVC 的 Controller,以 JSON 回傳資料,慢慢把現有 Web Form 抽絲剝繭到只剩下前端呈現邏輯,最後再重新開發 View 將原有的 Web Form 轉成 ASP.NET MVC 的 View。

 

7. ASP.NET MVC 是否能夠讓 Programmer 和 Art 完美分工?

永遠沒有「完美」這件事,我們公司的 Art 現在會用 Expression Web 設計網頁、自己規劃撰寫一些簡單的 jQuery 程式、自己規劃 MasterPage 與 Page 與 UserControl 等,現在只差把他教會如何用 Visual Studio 開發工具與如何使用 ViewModel 與基本的程式控制邏輯 (if, for, foreach, while, …),這些如果他都學會的話,我覺得已經很完美了。這是有可能的! ^_^

 

8. ASP.NET MVC 是否支援 REST

這是一定的,支援得非常漂亮!若要說 ASP.NET MVC 骨子裡就是以 REST 為主一點也不過份。

 

9. 對一個從其他語言 (Ruby, PHP) 跳過來接觸 ASP .NET,我在什麼樣的情況才需要導入 MVC 呢?

如果你是 ASP.NET 的新手,建議你還是可以學習 Web Form,因為市面上 Web Form 的書非常多,你只要跳過 ViewState 與控制項這些主題 (這條件好像已經過濾掉很多書了),其他部分在 ASP.NET MVC 都用的上。

相信我,對一個從其他語言 (Ruby, PHP) 跳過來接觸 ASP .NET 的開發人員來說,ASP.NET MVC 是你最好的選擇,你不需要像我一樣忍受 PHP 轉 ASP.NET Web Form 殘酷的陣痛期 (開發模式差很多)。

如果你學過其他語言的 MVC 架構,學習 ASP.NET MVC 也會得心應手,只要將一些基本的 .NET 開發技能學紮實一點即可,例如:C# ( VB.NET )、.NET 基礎、Visual Studio 開發工具、IIS、… etc.

其他必備的技能還有:HTML, CSS, JavaScript, DOM, jQuery, HTTP, JSON, … etc.

如果你有個好的網頁設計師能搭配開發,你可能還可以不用學 CSS,但其他技術可不能偷懶。

 

10. MVC 的架構真的適用網頁開發嗎?

MVC 是一種設計樣式(Design Pattern),不僅僅可用在 Web 領域,還有其他很多領域都適合用 MVC 來開發。若專講 ASP.NET MVC 就真的是為了 Web 應用程式開發而設計出來的 MVC 框架,非常適合用來開發 Web 應用程式,至於是否真的適合你用就要等你實際動手寫、動腦想、跌幾次跤就會有深刻的體會了,我自己的經驗是「非常適合」。

 

11. ASP.NET Web Form 會被 ASP.NET MVC 取代嗎?

綜觀的來看,你想想之前 ASP 轉 ASP.NET 的時代,至今已經十年,你覺得 ASP 被取代了嗎?還是有一堆線上的網站依然是用 ASP 開發而成的,而且還運作的不錯,所以,講「取代」是不切實際的。

微觀的來看,一間公司內如果決心轉向 ASP.NET,應該也會陸續擺脫 ASP 的牽連吧?同時維持多項不相容的技術長久來看成本很高,所以一定會先兩者並行,然後再徹底擺脫舊技術。

由於 ASP.NET Web Form 與 ASP.NET MVC 雖然在開發架構上有很大的不同,但彼此共用的技術非常多,例如:ASP.NET Application Life Cycle, ASP.NET Provider Model (Membership, Profile, SiteMap, …), Web Caching, Session, Authentication, … 等等。所以我認為兩者平行存在的時間可能會比 ASP 與 ASP.NET 平行存在的時間還更久,不過這只是「縱觀的來看」。

如果微觀的來看,如果你的公司決心將技術領域轉向 ASP.NET MVC 而你不願意轉型話,那麼你在這間公司的價值也會不斷降低,因為兩者開發模式差別甚大,在一間公司或同一個開發團隊中長時間維持兩種完全不同的開發模式不太明智,也許短時間內必須維護舊有系統一段時間,但時日一久必定整合為全新的開發模式,但此前提是「如果一間公司決心將技術領域轉向 ASP.NET MVC 開發框架」。

若已將現有 ASP.NET Web Form 程式全數轉移至 ASP.NET MVC 的話,也著實沒有將這兩個開發框架並存的必要性,我個人認為將開發框架從 ASP.NET Web Form 轉到 ASP.NET MVC 的過程是不可逆的,也就是當你愛上了 ASP.NET MVC 你就不會再用 ASP.NET Web Form 來開發 Web 應用程式,那種魅力與實際獲得的效益是不言可喻的。

所以這個問題如果要用一句話簡單回應,我會說:「老兵不死,只是逐漸凋零」

 

12. ASP.NET MVC 的除錯方式是否跟 ASP.NET Web Form 所有不同?

只有些許不同,由於 ASP.NET MVC 不使用 ASP.NET Web Form 的 ASP.NET Page Handler 處理網頁,所以內建的 ASP.NET 追蹤 ( ASP.NET Tracing ) 機制無法使用,必須改採 .NET 標準的追蹤機制,請參考 Trace 類別Debug 類別 等相關資訊。

其他在 Visual Studio 中的的偵錯方式如 中斷點、監看式、附加程序、…等常見的偵錯方式完全一模一樣,並無他異。

 


各位如果還有更多關於 ASP.NET MVC 的疑問,歡迎在此留言,等累積一段時間後我會整批回覆大家的疑問,謝謝。


 

相關連結

  

此文章由 will 發表於 2009/11/17 上午 11:38:15

永久連結 | 評論 (8) | 此文章的RSSRSS comment feed |

分類: ASP.NET MVC

標籤: ,

收藏:

相關文章

評論

十一月 17. 2009 12:50

ChrisTorng

使用伺服器控制項模式開發的第三方廠商控制項,是否不能再使用? 或者仍然可以使用,只是會破壞原本想維持的 MVC 架構? 有哪些已知的第三方廠商控制項有推出 MVC 專屬支援?

ChrisTorng tw

十一月 17. 2009 13:13

Will 保哥

ChrisTorng:

第三方廠商控制項,並非不能再使用,只要該控制項沒有強制使用 ViewState 也能運作,就可以繼續使用。我之前有寫一篇「ASP.NET MVC 開發心得分享 (3):與 WebForm 共舞」文章,建議你可以看看: blog.miniasp.com/.../...-Dancing-with-WebForm.aspx

在 ASP.NET MVC 的領域也有稱為「ASP.NET MVC 控制項」的概念,通常代表的是 ASP.NET MVC 中的 HTML Helper 方法,目前國外已有廠商推出專屬 ASP.NET MVC 的控制項,例如:Telerik Extensions for ASP.NET MVC ( http://www.telerik.com/products/aspnet-mvc.aspx ) 目前是以 GPLv2 的方式釋出,是完全免費且開放原始碼的。

Will 保哥 tw

一月 22. 2010 15:49

Kairay

我是從java轉換到.net開發環境,個人覺得ASP.NET MVC架構蠻好上手的,Model部分再用entity framework應該就蠻完美的。
不過目前看來,它好像只能使用"專案"形式,不能用"網站"形式來建立project,
關於這點...可能是我不會使用這個framwork的原因...
在考慮多人協同開發一個專案下,通常我們會對於aspx、cs、html等進行版本控管
當程式有幾百支、view有幾百個之後,常常會有某某東西忘記加入專案然後complie又過的情況發生
所以有時候程式deploy上去,會有人反映怎麼我寫的程式不見了....
我目前有個專案就是這樣...搞得很麻煩

Kairay tw

一月 22. 2010 21:20

Will 保哥

Kairay: 這種狀況偶然會發生沒錯,我的團隊成員也曾經忘記將新增的檔案加入到「專案檔」中,以致於部署的時候漏了檔案,但通常被罵過之後通常不會再犯,而且我們也有人定時在看有沒有 Views 目錄下有沒有被隱藏(沒有加入專案)的檔案,再者,這種問題通常會發生在團隊新成員不熟悉 "專案" 形式的情況,或專案初期檔案變動性較大的情況,像我們專案開發到後期幾乎沒發生過此狀況。

這部分透過教育訓練總是能解決的,我覺得至少對我來說不是個問題,畢竟你要讓一個多人協同開發的專案透過「人性」降低犯錯的機率似乎也不應該是個理由,通常還是要有人做 QA 比較妥當。

Will 保哥 tw

一月 23. 2010 23:34

Kairay

我覺得這是開發工具本身就可以解決的問題,如果VS能列出未加入專案的檔案列表,不就節省了很多資源成本,工程師面對的開發環境也可以更單純...

Kairay tw

一月 24. 2010 02:57

Will 保哥

Kairay: Visual Studio 的確能列出未加入專案的檔案!請看以下圖示連結: img193.imageshack.us/img193/7063/2010124025513.png

Will 保哥 tw

一月 25. 2010 09:11

ChrisTorng

使用 TFS 時,可以在原始檔控制總管中,對資料夾按右鍵,選「比較」,就可以列表找出本機與 TFS 中所有的差異,並可以比較檔案內容、同步、簽入、刪除等。我偶爾也會使用這個功能。
而團隊開發方面,只要在 VS 裡加入的檔案,很少不會加入 TFS 的,只有偶爾在簽入時,漏掉一些檔案未簽入,導致其他人抓新版時會出問題。只要請上一個簽入的人再補簽遺漏的檔案即可。
我也規定大家簽入時要全部檔案簽入,不要簽入部份。因為有人喜歡好幾個功能混著做,某一個寫好後先簽某一個,其他保留不簽入...這樣就很容易出問題...只要每一次都全部檔案均簽入,就不太會有問題了。

ChrisTorng tw

二月 6. 2010 16:04

鬼

我還沒有使用 MVC 的經驗(汗),但打從開始接觸 asp.net,我就只用 Web Application Project 的方式開發客戶的網站。我們客戶的網站包山包海,同一個虛擬目錄的 page 數破萬,很多子系統互不相關,放在同一個 web site project 實在太笨重了。我們每一個專案的功能切得還算細,每個人負責一個專案,倒沒有擔心過 VSS 多人維護上的問題,而且編譯的速度還算可以 ^_^

我有試過 Web Application Project 產生的 DLL 和 Web Site Project 產生的 DLL 放在同一個虛擬目錄的 bin 下面會打架,Web Site Project 的 aspx 可以執行,Web Application Project 的 aspx 會出現錯誤,請問 MVC 架構下的的 DLL 會不會跟這兩者打架呢?

請問 asp.net 的 validation 是否綁在 view state 內?如果使用 MVC 的架構,是否得自己去檢查一個個的欄位是否有惡意的輸入呢?有沒有懶人用的方式呢?

tw

新增評論


(將顯示您的Gravatar圖示)  

  Country flag

[b][/b] - [i][/i] - [u][/u]- [quote][/quote]



線上預覽

三月 12. 2010 18:07