台灣最大程式設計社群網站
線上人數
1786
 
會員總數:245248
討論主題:189105
歡迎您免費加入會員
[]  
[我要回覆]
回應主題 加入我的關注話題 檢舉此篇討論 將提問者加入個人黑名單
.NET MVC ?
價值 : 0 QP  點閱數:844 回應數:0

樓主

Mark Shu 版主
中級顧問
42091 589
15011 3773
發送站內信

捐贈 VP 給 Mark Shu

.NET MVC開發方式,是在.NET自從.NET2002推出後數年,至.NET2008才新增的開發模式..

開發方式較類似JSP、ASP,將程式碼嵌入HTML,和原本.NET推出後強調的程式碼和HTML分離不同,.NET MVC以View、Controller、Model的方式切割呈現、控制、資料存取,但原Web Form的開發方式,一般也本來就是以如此的模式開發,不可能將按鈕按下去後的Click事件中,去寫所有的程式碼,本來就會切割,而.NET的MVC是
讓開發時就強制必須去切割,才能運作,而原有的Web Form Server Control開發方式,頁面只有html、css、javascript,相關的事件都是在CodeBehind或CodeBeside中去實作,正常來說事件中並無太多程式碼,因為一個專案會切割展現層、控制層、商業邏輯層、資料存取層,因此當aspx中的Button的Click事件在.aspx.cs中被觸發時,Click的Event中,並不會有太多的程式碼,它基本上只做些UI輸入值的格式驗證或簡易的運算,因為它主要會去Call控制層,控制層會去控制並呼叫
商業邏輯層,而商業邏輯層運算處理後,會再去Call資料存取層,然後運算後由控制層接收到資料,再回傳給UI也就是aspx去呈現,因此,除非程式碼是一條龍的撰寫方式(或沒有經驗的工程師),也就是當Button_Click被觸發後,裡面撰寫了包含商業邏輯、對資料庫的存取、及其他運算,否則以上述切割分層的架構去開發,本就符合MVC的精神,且MVC是很多程式語言再使用的設計架構,並不是.NET內建的MVC才叫MVC,它只是強制開發者避免用那種一條龍的方式去開發(沒有做到重複使用、抽離、單一維護),另外上面說的商業邏輯層、資料存取層可能是WebSerice、WCF,或是一個方案中分別的三個獨立的專案,自行調整架構的彈性,Design Pattern本就該由資深工程師或系統設計師依專案特性去設計,並非一定要依賴開發工具去代為強制做系統設計


當轉換為Windows Form時:
若是將程式碼或程式控制嵌入UI中,若是Web Based要改成Windows Form要如何迅速轉換?程式碼夾雜商業邏輯甚至對資料的運算存取,要如何抽離那些夾雜在html和<%包裝的程式碼%>,一般只有Model可以直接使用,
剩下無法套用的View的部分不用說,Controller中則必須要把ActionResult中可用的部分抽離,剃除那些如ModelState.IsValidate、
return View等.NET MVC使用的程式碼,若是Model中又套入了.NET MVC機制的資料驗證,如[Required](System.ComponentModel.DataAnnotations.RequiredAttribute),那對轉換到Windows Form也是無用的程式碼,在Windows Form的開發上,資料格式的驗證會在按下按鈕時做驗證,通過後再把資料往後送,不會放在資料存取層才去做,也是必須要修改,那整個轉換過程變成要更動太多,若是以上述自定的設計模式,商業邏輯層、資料存取層都是可以幾乎原封不動的複製並再次利用,Windows Form的按鈕Click事件要做的事情,就複製Web Form的按鈕Click事件要做的事情,因為事件中要做的事情幾乎一樣,重要且大部分的事情都是去呼叫另外兩個獨立的專案(商業邏輯層、資料存取層),因此可以迅速的轉換,這也是展現層要和任何程式碼切割的益處.


程式碼可讀性:
UI和程式碼本就該徹底分離,一個夾雜著HTML、CSS、JavaScript、c#、還有迴圈(如產生Table)、<%...%>、<%: ...%>、<%= ...%>、@{...}
if else、foreach...,server code和client code夾雜不分,若是一個開發好的網站要調整Style,美工根本不懂程式碼,若調整時,在眼花撩亂的夾雜程式碼中,美工人員不小心動到程式碼,又要如何釐清責任,在專業分工的前提下,美工人員負責頁面的設計,程式人員負責程式碼的撰寫,本就應該盡量抽離兩者的關聯,以順利分工,也分離責任


伺服器控制項:
Web Form的Server Control,有對應的屬性和事件可以實作相關的功能,每一個html tag都有對應的控制項,完全達到物件導向的設計,除了後端程式碼,連頁面的控制項都有專屬的屬性和事件,也一併用了物件導向的觀念,之所以會被說難用,那是因為缺少練習範例和閱讀MSDN技術文件,以GridView來說,若不夠熟悉,會覺得無法駕馭,那
當然要靠練習,況且也有<TemplateField>可以自定樣板格式,一個新的技術當然一定會有新的東西要練習和學習,若不夠熟悉必定會覺得難用,對一個新手而言,雖然剛開始必然會投入學習成本,但隨著開發到後續面臨的維護問題,效益會逐步趕上成本


程式組合html字串:
原本.NET的出現,是要簡化那些過往的組合HTML的開發方式,希望工程師能把重心放在商業邏輯,而若是一個開發過程有相當多的組合HTML字串工作,若組合的HTML標籤沒對稱、漏打、少打、或對應的標籤名稱打錯,雖然資料是對的,但卻格式跑掉,要回頭來檢查那些組合的大量字串問題出在哪,而原本Web Form是在控制項樣式、設計好後,再來就只剩資料正確與否的問題,能迅速且明確的切割,格式的問題,調整控制項的屬性,顯示的資料不正確,則查詢資料存取的問題,因為和顯示樣式無關,資料的問題歸資料,顯示的問題規顯示,若把大量的精力花在組html這種工作,不如把精力放在系統的開發架構設計、資料庫設計、效能和安全性、商業邏輯的釐清,另外若Style要更改,
也必須要去從組html的字串中,去找出對應的位置,而不是可立即修改該顯示控制項的屬性,從頭到尾花在組合、檢查、找出、調整html組合字串的時間過多,若是商業邏輯複雜的系統、SQL複雜的系統,光是解決那些問題已力不從心,何來更多的精力和時間去耗費在組合、調整那些大量的HTML字串,原本.NET做掉並簡化了展現層,就是希望不要耗費過多的精力在類似的調整和組合上


後續維護:
若一個開發好的網站,因客戶的需求於後續做修改,若一個組合大量HTML字串完成的TABLE,原本沒分頁功能,要新加上分頁的功能,這時又要去動組合HTML的字串和加上其餘的分頁控制程式碼,若是以物件導向的方式開發,可能只需再增加一個GridView的PageIndex_Change事件,並設定控制項分頁功能所需的屬性,取對應頁數的資料回來,並繫結到控制項即可,維護非關顯示樣式的問題時,本就不應該再去修改UI內的任何程式碼,以免動到UI內的HTML,當然前提是必須完全切割開來,否則可能會造成無窮迴圈,修改UI時動到不該動的程式碼,修改程式碼又動到組合UI的字串


設計階段時:
以組合HTML字串的方式,以迴圈產生TABLE來說,在設計階段切換到.NET的設計模式,並無法看到TABLE的樣貌,而是一片空白,執行階段才可看的到,若是以伺服器控制項來設計,在設計時就可以切換到設計模式,觀看控制項呈現的樣貌,剩下的只剩資料的問題,在執行階段只要專心在資料的正確與否即可,這時就和頁面顯示無關,只要FOCUS在資料的問題,可以明確的、迅速的切割並找出問題,在設計頁面呈現樣式的階段,就專注在頁面上的佈局和呈現,並在設計階段就進行調整,在執行階段就專注在資料是否正確的存取,在HTML和程式碼夾雜的狀況下,有可能在設計UI的階段看不到呈現的結果,執行階段時若發生錯誤,則有可能是資料錯誤、有可能是跑迴圈組字串時的字串中HTML的標籤沒有對應,徒增問題釐清的難度,而且耗費太多精力在組字串的工作上,這原本在WebForm的開發模式可以做掉的部分,可以讓工程師專心在商業邏輯和資料存取的用意,卻大打了折扣

 

建置與佈署
.NET MVC架構在建置過程無法立即發現錯誤,UI也無法以所見即所得的方式立即調校,程式碼的部分則須待執行時期才可發現錯誤,如:<%: Html.ValidationSummary() 123 %>、<% What 123 %>、<%= 3939889 %>、<%: 瑪麗亞%>,如此建置時並不會發生錯誤,但執行時會出現錯誤,遞延開發上耗費的時程,也未充分發揮開發平台的立即發現並更正的效用,並延長立即發現並修正錯誤的時間,佈署時除尚須安裝.NET MVC Runtime於Server,此皆為需要考慮的問題.

 

後續的發展
MVC 3 Razor 相對於MVC 2 又變更了些撰寫方式,以@取代<%%>..簡化了頁面眾多的<%%>,另外也沒有所謂的設計模式了,頁面的設計樣式和資料的正確性,全部都要Runtime才可以看見,這要花更多的時間在對頁面的佈局調整,也無法在頁面設計階段就能立即看見並調整網頁的呈現樣式,執行階段要同時兼顧可能是展現層的問題,也可能是資料正確性的問題,無法切割Presentation和Data的開發方式,另外跑迴圈組Table的老方式,也許已讓人看不出設計開發的效益,所以出現了類似WebGrid這樣的Html Helper,可指定資料的繫結來源,並設定要顯示的欄位,且內建排序和分頁,這幾乎又走向了Web Form的GridView,不過就是繞一個圈,要物件導向的方式開發,就徹底的物件導向,走了一大圈還是要繞回原點,因為跑迴圈組HTML,把組好的HTML呈現在瀏覽器上,這對開發設計系統來說並無實質的幫助,也不是.NET開發工具出現後,能在2002開始能存活到現在的誘因,因為不能夠簡化開發工作,不能提升開發效率,對專案就不會有正面的幫助,開發複雜或大型的系統,花過多的時間成本在原本開發工具可以做掉的展現層,並無太多意義,MVC設計模式,並不是要工程師花更多的精力在展現層,而是整個系統的展現、控制、商業邏輯、資料存取的系統開發架構的設計,不是把專注力放在如何呈現,而是要更專注在系統的商業邏輯和資料存取,更甚至系統的安全性和效能,另外更不是要把<%%>包進HTML才能實現MVC設計模式..,.NET 的MVC適合用在小型網站的開發,若是一個大型系統的開發,更要考量系統的後續維護、延展、擴充,甚至整個Design Pattern都要依據系統的特性去規劃和設計,不可能什麼狀況下都用內建的開發方式.

 

效益與成本
實務上也發現為了以.NET MVC架構去開發網站,決策者當然也深知許多原本ASP.NET所提供的開發效益無法展現,因此為了處理像HTML TABLE這樣的問題時,TABLE中要包含分頁、排序、編輯、刪除、明細顯示、樣式變換...等,若以迴圈組合HTML字串的方式,在開發、除錯、維護、需求變更階段時,已浮現出許多層面的糾結,因此以額外的成本去解決,如購買Telerik或其他第三方開發的元件的方式,來彌補失去效益的落差,在ASP.NET的開發平台上原本就已經提供多類的伺服器控制項可達到TABLE的物件導向化開發,卻在面臨一個過於複雜的系統開發時,要去購買額外的元件才能達到原本就已經提供的控制項功能,除了增加額外的成本,也變成遠水救近火,專案全時程耗費過多的精力和成本在處理UI的問題,又如大量的運用jQuery,但jQuery版本更動速度快,且新的版本有無法向下相容的問題,一個系統的核心,最不該被忽略的是在於商業邏輯和資料流的處理,安全性、效能性、維護性、延展性、擴充性、整合性...,有太多的重點,而不是將核心擺在網頁的呈現面,幾乎已經變成了...已經坐上了飛機,卻帶著一台腳踏車一起上飛機,然後在機艙內不斷的騎著腳踏車,試圖想比飛機先到達目的地...

 

開發工具的被接受度
這從商業面來說,VS.NET希望推出後,能被極大化的使用者接受並嘗試使用,所以包含了VB.NET、C#、J#、F#、Visual C++...,曾發現以前寫VB6、ASP的人會偏好VB.NET,以前寫JAVA的人會偏好C#,表示已成功的拓展讓JAVA工程師可以順利轉換並接納投入,本身從JAVA轉換時也曾感覺、.NET似乎是為JAVA工程師打造的,如Class、Interface、繼承、封裝、多型的概念及語法的相似度,幾乎和寫JSP、Servlet、Java Bean差異不大,但寫了數年甚至十餘年的ASP工程師呢,經驗值的差異大必然造成轉換的門檻,因此在ASP.NET中..一種比較類似ASP經驗值的架構被推出來了.

 

設計與開發
為了套用.NET MVC的運作機制,對系統設計有一定程度的限縮與發揮的侷限,另外原本早期在做ORM時,是自行要針對資料庫TABLE撰寫成Accessor對應資料庫欄位的Table Class,但後來陸續有Strongly Typed TableAdapter、Linq To SQL、Entity Framework..的出現,即不用再去做Table Class的對應Class製作,因皆為強型別的資料表的資料欄位對應物件類別,伺服器控制項可直接繫結與運用,程式碼也可直接操作對資料的異動或存取,但.NET MVC為了達到Controller將Model傳遞到View的機制,必須去撰寫Table對應的Class,將資料表的結構傳遞,另外Model設計上應是一個動作的資料流的終站,將實際對資料進行異動,因經由操作介面進入的資料應在展現層撰寫驗證、再經由商業邏輯的處理或運算,但.NET MVC的機制,是利用Model這層對經由UI輸入的資料進行驗證的判斷,如Require、Length、Data Type...等,雖然運作機制是正確的,但理應由UI層去控制才是,這些都是異處.

 

要操作組合HTML字串或是操作伺服器控制項,端看整個系統的設計、開發、維護各階段所需的投入成本,要挑選何者開發模式自行體會與選擇,但MVC是個設計系統的模式,並非一定要套用特定開發工具內建的固定架構寫法,才叫做MVC,或是名稱上有MVC的技術才是MVC,另外,並不是以Web Form的Server Control的方式開發,就一定不是MVC,那是整個的系統設計模式,重點在如何規劃設計,所以也無須誤以為在頁面裡面看到<%...%>、<%=...%>、<%: ...%>、或@{...}夾雜在HTML內,那才是MVC..,那只是ASP.NET內建的其中一種開發方式,名稱叫做.Net Mvc...,更也不是在.Net Mvc這個內建的開發架構沒推出之前(ASP.NET 2008),用.Net開發的系統都不是MVC,Windows Form、JSP、PHP...都可使用MVC架構去設計開發系統,他是一個Design Pattern,不是屬於任何一種程式語言或任何一種開發工具內建的開發模式,內建的特定開發模式只是輔助、簡化、或...限縮了系統設計而已.

 

實際上任何技術都是一個選項,但不能成為藉口,.NET將HTML的元素物件導向化後,必然造成要投入許多心思去看如MSDN技術文件,及練習實作範例,變更原來的固有開發觀念,但當兩個成因形成時,就絕對不會去用他,第一個是無法承受學習成本或壓力,覺得過去內嵌式所累積的開發經驗會歸零,所以抗拒,第二個是真的學不起來,那是因為過去的包袱太重,一杯裝滿水的杯子,若是不願倒掉,是永遠無法再裝入一滴水的,就像過去的 XP作業系統,已經成為很多人的習慣,當微軟宣布不再支援更新時,很多人去買新的電腦時面對當時的Vista或Windows 7,第一個問的就是:老闆,可以降級成XP嗎?...... 若是永遠都在用降級來適應新的事物,那要如何能破關,就算是線上遊戲打怪,也應該是不斷的磨練,以期能快速升級才是...

 

 


本篇文章發表於2012-02-07 19:54
== 簽名檔 ==
猛虎別在當道臥,困龍也有上天時。


別忘捐VP感謝幫助你的人 新手會員瞧一瞧
目前尚無任何回覆
   

回覆
如要回應,請先登入.