專刊內文

當前位置:首頁>專刊分享>內文

瀏覽次數 : 9639



 

一起走向MVC(上)

訊光科技 / Andy Kao  

前言

         EEP這個架構,是在1999年Delphi5時代就被我們的研發團隊所創,當時是為了解決Client/Server中Client的版本更新與滿足SOA架構以集中服務層級、並讓商業邏輯與使用者介面可以分開開發與處理;隨著Delphi沒落,2005我們重新以Visual Studio為基礎打造新的.NET EEP平台,這個架構沿用至今也都已經快12年了,一路上UI從Windows走向APS.NET到現在的JQuery、APP與RWD技術等等,無論UI如何變化,商業邏輯寫在EEP Server端始終可以繼續沿用,這也是為何麼今天EEP在國內平台技術上始終屹立不搖原因。

        隨著ASP.NET MVC的流行與成熟,一直有客戶詢問我們EEP如何與ASP.NET MVC結合,或說EEP是否支援MVC的開發模式,隨著微軟的Visual Studio 2017發表,終於,我們的研發團隊也開了第一扇MVC的窗,開始支援你在EEP使用MVC的開發模式,並可以沿用原來的EEP A/P Server上所寫的商業邏輯與資料存取服務等。

何謂MVC

        MVC 是一種網頁設計的模式, 將網頁設計的程式分成三個部分,MVC分別代表Model-View-Controller,三個部份的程式相互交互使用,Model代表模型,也可以視為資料源;View代表輸入及輸出的介面,通常就是指User可以看到的網頁(如HTML);Controller代表控制器,用來控制網頁的動態顯示即處理User的輸入邏輯,如查詢條件或輸入規則等,如圖及以下的說明:



模型(Model): 模型通常是指企業資料和業務規則。在MVC中,模型通常擁有最多的處理任務,因為他要負責提供資料給Controller,並處理Controller回傳的資料,如何以商業邏輯的處理後存入資料庫等,通常Model是極為中立,不受Controller所影響,也就是一個Model可能對應多個Controller,只需要一個Model模型即可,減少了存取程式的重複性開發。

.視圖(View): 視圖是User所能看到的網頁內容,並透過網頁與User互動,簡單來說,視圖就是由HTML元素組成的網頁介面,在新式的Web應用程式中,HTML還包括了CSS等樣式表語言;通常View是透過Controller動態產生給User的網頁,而非固定的HTML網頁,User的操作與交互也是透過Controller來與View與Model產生交互作用。

.控制器(Controller): 控制器負責向Model請求數據並提供給View顯示給User網頁資料,當User在View頁面上操作互動時,也是透過Controller來告知Model重新提供資料;如果User在View中輸入資料,也是透過Controller來檢查核對正確性之後透過Model存入資料庫中。

        MVC的開發概念與傳統EEP N-Tier開發概念是有點類似,差異在N-Tier僅是將商業邏輯與使用介面分層開發與斷開耦合,長期以來已經成為多數應用系統的開發標準;到了MVC這個時代,除了Model與N-Tier的業務邏輯層相似外,你可以把View與Controller視為N-Tier的使用者介面,只是Controller要負責讀取Model資料並綁定給View,並妥善處理View(就是User)的操作反應,這與之前使用者介面開發方式有較大的不同。

為何要使用MVC

        早期的網站寫法,不管是ASP還是PHP或是ASP.NET,都會有個缺點,程式寫在一起,舉ASP.NET為例,通常ASPX及CS中會有HTML、JavaScript、C#、XML Tag等,如果是資料處理還會有SQL語法及處理資料的CS商業邏輯等等,可想而知有多麼複雜與難以維護,如果加上為了美觀把視覺美工設計的HTML文檔與CSS加進來,就好像惡夢一般的低效循環,這也就是為何要推出MVC的開發模式來改善此問題,如下:

1. 分層避免重複開發: 如同EEP的架構一樣,將後端的商業處理邏輯與前端UI分離處理,為了讓後端只要開發一次,就可以讓Windows/Web/App共用一份後端商業邏輯,除了避免重複開發,也可避免前端的UI程式夾雜了商業邏輯的處理而難以維護。MVC的方式把User的操作行為與後端的處理商業邏輯完全分開,使得系統可以各自獨立,可讓多個View共用一個Model避免重複開發。

2. 讓前後端避免耦合: 很多前後端的程式都是緊密耦合在一起,通常改了前端影響到後端,改了後端又影響到前端,大大增加維護的困難度。採用MVC的開發模式,前後端都靠著Controller來彼此互動,通常改變最多的是使用者介面,在MVC中只要改前端View的HTML與CSS,配合更改Controller即可,後端通常可以不用更改,而且不會彼此互相影響。

3. 分工開發: 網頁的開發通常會有後端的開發人員與前端的開發人員,因為彼此的技術領域不同,為了達到較高產能會採用專業分工,在實際的技術領域中也是這樣分類的,使用MVC非常容易讓前端開發人員與後端開發人員分工出來,通常前端人員要負責Controller的開發(這個比較正統一點),但也有團隊把前端View交給UX設計人員來處理,Controller則交給後端人員來處理;無論那一種分工,都可以很容易透過MVC開發模式達到彼此干擾最小,日後維護系統更為容易的目的。


MVC不是萬靈丹

       MVC當然不是萬靈丹,別天真以為所有的應用網頁都使用MVC方式來開發好了,MVC也是有存在的缺點,通常最直接的建議是,小專案(項目)不要使用MVC來開發,簡單說明如下:

1.定義不清楚: 傳統開發者要弄懂MVC並不是很容易,無法快速學習,必須花點時間開發經驗的累積才能規劃的比較合理,由於Model和View要嚴格的分離,也讓程式的Debug帶來不便,測試工程的量也變多了。

2.成本與團隊考量: 使用MVC開發模式的成本並不會降低,如果你的網站項目是1~2人內的小團隊,用MVC更是覺得可笑,一個人反而要扮演多個角色,開發週期與成本也不會因此而降低,沒有經驗或規劃不好反而會讓成本增加;唯一的好處就是以後維護會變得比要容易一些。

3. 增加系統結構的複雜度: 就是說不要為MVC而MVC,有時候一個簡單的頁面,嚴格遵循MVC,使模型、視圖與控制器分離,會增加結構的複雜性,也就說用MVC搞得讓程式變成複雜許多是不值得的。

4.執行效能也許會降低: 一個互動頻繁的頁面,透過Controller與View交互,如果沒有需要動態更換Model的數據,有時候比使用JQuery方式還慢,因為MVC的User操作會透過網路回來Controller,透過Controller又去更動View的網頁內容;反之如果需要交互Model的動態資料,MVC的執行效能就會比傳統的JQuery還好些。也就是說如果是一個簡單且沒有很多互動的網頁,透過MVC封裝,可能引發過多的更新操作,降低了執行效率。

EEP的MVC架構


         如圖,為EEP的MVC架構,因為是基於ASP.NET的MVC5架構所發展,所以盡量配合微軟的MVC基本架構來思維。為了能與原來EEP的系統相互結合,將EEP原來的A/P Server上的InfoCommand(資料讀取組件)與UpdateComp(資料回寫組件)等Server端元件做成了MVC裡的Model,也就是說你可以直接以之前EEP所開發的Server端模組作為MVC的Model,連同Server Method(商業邏輯處理方法)都可以沿用,讓你無須因為MVC而重寫Server端程式。

        Controller與View在EEP2017中,會以EEP Wizard幫你自動產生對應於Model的Controller(交互控制器)與View(前端網頁)。Controller內會包括如何透過Server端的Model存取資料庫;View則會針對Model所選的Table與欄位自動產生在View網頁中(會生成以Bootstrap為主的RWD網頁),並透過Controller互動,可以完全不更改程式下即可完成一個簡單的MVC網頁程式,也可以針對產生的Controller與View來進行個性化的更改,滿足使用者多變的特殊需求。



結論

        MVC的開發模式中,多數的View與Controller的程式都是鬆耦合的獨立程式,很難讓不同的頁面可以共用或重複使用,對於開發者Coding工作而言,還是增加的不少負擔。目前EEP在Server所產生的Model,因為沿用了原來EEP Server端的組件,所以算是高度元件化的架構;但View與Controller暫時也只能用Code Generator方式來產生對應的程式碼,達到View與Controller間的交互作用,其實,是可以把部分View採用JS組件的方式來產生網頁,這樣可以讓View提高組件化並更容易開發與維護,這也是EEP MVC的下一步發展。

        EEP的 MVC架構只是起個頭,要做到不必寫程式又能滿足多數人的需求,其實是蠻難的,還有一大段路要走,隨著開發者對於MVC的需要與相關技術的精進與成熟,值得我們的研發團隊持續加快研發腳步,讓我們持續關注MVC吧。