|
一起走向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吧。 | 
