■ What is MVC?
| MVC,Model-View-Controller Separation 樣式(Pattern) |
|---|
|
MVC Pattern 其實就是在 Model-View-Controller 三者之間作一個責任的釐清：
- View：專注於畫面設計，不牽涉資料與邏輯處理。
- Model：反應企業領域中真實世界的概念，例如“員工”、”部門”等物件。在 ”員工”物件中，它專注的責任在於取得(Get)及設定(Set)員工相關的資訊，並負責所需處理的企業邏輯(Business Logic)，如計算員工紅利等 ; 而“部門”物件，則可以取得及設定部門相關的資訊。
- Controller：承接 View 與 Model 的中間角色，以維護 View 與 Model 兩者之間的獨立性，並負責控制及協調 Model 內物件的互動邏輯。它的角色就好像是公司的總機小姐，當外部的使用者打電話(View)尋求該公司的幫助時，總機小姐(Controller)會依需求的不同再轉達需求至可以服務的部門工作者(Model)。
而且 View、Controller、Model 有著分層的關係，View 可以看見或者傳送訊息到 Controller或 Model 物件，反之，Controller和 Model 物件將會忽略視窗畫面的存在。
未了解 MVC 樣式，而把這些物件都混在一起，使用者介面程式往往亂成一團。
MVC 解開糾結，增進彈性及再利用性！
■違反 MVC 的設計：兩層式(Two-tiers)的結構
從使用者的觀點來看，開發人員以所謂 4GL 工具快速建立使用者介面(如 PowerBuilder)，從畫面上得知系統需提供什麼樣的功能給使用者，然後軟體開發人員就據此至共用的資料庫“撈”資料來處理。此時，開發人員將企業規則等應用程式邏輯，要就寫在使用者介面端的 Script Language 上;或者就寫在資料庫的 Stored Procedure 上，如上圖 2-tier 的架構，而造成企業邏輯的分散，不容易維護。
顯然地，將企業邏輯寫在前端介面，明顯地違反了 MVC 設計原則：Model 與 View 物件的分離。而將企業邏輯寫在資料庫，似乎比寫在前端介面好一些，事實上，情況也好不到哪裡去，觀察 MVC 的設計，其主要目的是為了要保護 Model 物件–亦即企業物件(Business Object)，因為 View 物件是善變的，為了不讓因 View 物件的變動而牽動到 Model 物件，所以才將 View 所傳送過來的需求(Request) 封裝在 Controller 物件裡。
所以，從 “變” 的角度來看時，亦可以知道將 Model 物件表達在資料庫，並不符合現代 e 化系統的特質：異質、分散–資料庫也是善變的。
因為從變動的週期來觀察，我們懂得來分析物件的細緻度(fine-grained)。例如，一棵樹從 “變” 的週期來看時，就會區分出“樹幹”、“樹枝”、“樹葉”.. 等。
相對，觀察從 View、資料庫、Model 等其生命週期的不同，自然地，我們應該可以分為三個元件：Presentation、Business Logic、DataSource。反映出來的結構也就是所謂三層式或多層式的架構了，如下圖：
