[鐵人賽Day02] ASP.Net Core MVC 進化之路 - 什麼是MVC

文章一開始筆者先自嘲一下,

筆者剛開始接觸MVC的時候,

一直以為這是一套微軟特定的開發技術,

後來才知道它只是命名剛好有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

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

View

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

 

其實微軟的MVC的裡面還有眉眉角角,

舉資料繫結(Data Binding)的順序周期為例,

雖然平常都不會注意到它,

不過當踩到雷多痛幾次之後,

你就會發現這些東西超重要!

 

礙於文章篇幅,就先告一段落,

後面提及時再一一做介紹。

下篇就要開始ASP.Net Core MVC了!

GOGOGO!