前言

文章一開始筆者先自嘲一下，
筆者剛開始接觸MVC的時候，
一直以為這是一套微軟特定的開發技術，
後來才知道它只是命名剛好有MVC而已。

同步發表於個人點部落 - [鐵人賽Day02] ASP.Net Core MVC 進化之路 - 什麼是MVC

What is MVC?

所以什麼是MVC呢？
正確來說MVC是一種軟體架構，
這個名詞最早出現在1978年一種名為smalltalk的程式語言，
分別代表Model(模型)、View(檢視)、Controller(控制器)，
能讓前後端的程式碼職責分離。

但這整個流程是如何運作的呢？
在這之前我們要先簡介紹一下Web的流程。

假設我想知道今天台北的天氣狀況，
在瀏覽器中點選中央氣象局連結後，
首先瀏覽器(Client)會發起一個Request(請求)到氣象局的網站(Server)，
接著Server會去訪問DB(資料庫)今天台北的天氣怎麼樣，
最終將訪問後的結果包裝成Response並呈現在瀏覽器畫面上。

我們來看看MVC的架構：

如果你滑到上面比對一下應該不難發現，
這兩張圖在某種程度上是非常相似的。
事實上MVC也是遵照這樣的模式運作，
只不過將各自的職責拆開而已。
對於MVC名詞的解釋google後可以得到很多解答，

以維基百科為例：

• 控制器（Controller）- 負責轉發請求，對請求進行處理。
• 視圖（View） - 介面設計人員進行圖形介面設計。
• 模型（Model） - 程式設計師編寫程式應有的功能（實現演算法等等）、資料庫專家進行資料管理和資料庫設計(可以實現具體的功能)。

一樣是剛才天氣查詢的例子：

當瀏覽器發起請求(今天台北天氣如何)之後，
Controller收到請求後會負責分派工作給Model，
而Model主在負責與資料相關的處理過程，
所以Model會去幫忙問資料庫今天的天氣狀況，
假設資料庫存的溫度欄位是華氏而畫面上需要顯示攝氏的話，
那在Model內也會進行溫度單位轉換的工作(資料處理)，
最後Controller負責將查詢並處理完的資料包裝成Response再丟給View去呈現。

嗯！一切看起來合情合理，
不是說好MVC是為了實現關注點分離嗎？
那為什麼Model向DB要資料後還要做資料加工(商業邏輯)的工作呢？
廣義的定義Model的確概括了所有資料處理的責任，
而筆者個人認為資料處理又可分成資料加工跟資料存取兩個部分。

• 資料加工：針對原始資料做加工(EX:字串拆解、組合、數值計算、單位轉換)等功能。
• 資料存取：僅負責與資料庫之間的資料傳遞(資料異動或資料查詢)。

在開發中除非專案真的小到只有兩三個功能(應該很少這種系統吧)，
否則我會在Controller之後再多加上商業邏輯層及資料存取層，
如此一來，Model的功用就是純粹拿來當作裝載資料的容器了。

而實際上還是會依團隊習慣有特定的架構分層，
例如有些公司會將BLL層改為Service層，
或將DAL層改叫Repository層(套用UnitOfWork分層)等，
筆者僅是將自己常用的架構提供給大家參考。

文末簡單記述一下筆者對MVC各層的介紹。

Controller：
角色就像是工頭的地位，負責指揮工作流程及執行順序。
是所有請求(Request)的第一線入口，所以驗證及授權通常也會在進到Controller時檢查。
決定回應(Response)瀏覽器的狀態代碼(HttpStatusCode)及內容。

Model：
主要是用來裝載資料的容器，而資料加工及資料存取的工作則委派給BLL及DAL層處理。
又可分為資料庫的原始Model及呈現畫面用的ViewModel。
ViewModel在設計時盡量保持純淨(不要加入帶有邏輯的程式碼)，若逼不得已則以擴充方法(Extend Method)方式為其擴充。

View：
負責將資料呈現到畫面上。
一個View僅能對應一個Model，若需要多個則使用ViewModel進行組合。

其實微軟的MVC的裡面還有許多眉眉角角，
舉資料繫結(Data Binding)的順序周期為例，
雖然平常都不會注意到它，
不過當踩到雷多痛幾次之後，
你就會發現這些東西超重要！

礙於文章篇幅，就先告一段落，
後面提及時再一一做介紹。
下篇就要寫開始ASP.Net Core MVC了！
GOGOGO！