ASP.NET MVC 系列1 - MVC簡介

目前 ASP.NET 已發展至3.5,它是由 ASP.NET 2.0 為基礎,並加上原生的 AJAX 支援以及 .NET Framework 3.5 的新特性、例如可以在ASP.NET裡面使用LINQ的語法,以及加入一些新的控制向(ListView、 DataPager),原有的 ASP.NET 2.0 應用程式仍可以在 ASP.NET 3.5 上執行。

目前 ASP.NET 已發展至3.5,它是由 ASP.NET 2.0 為基礎,並加上原生的 AJAX 支援以及 .NET Framework 3.5 的新特性、例如可以在ASP.NET裡面使用LINQ的語法,以及加入一些新的控制向(ListView、 DataPager),原有的 ASP.NET 2.0 應用程式仍可以在 ASP.NET 3.5 上執行。

然而過去在開發ASP.NET的網站系統時,我們可以很方便的從工具箱(ToolBox)拖拉我們要的元件到網頁上,開發方式也與桌上型的應用程式(Application)沒甚麼兩樣,對於剛開始學習寫網頁程式的人來說門檻相對的降低許多,但是隨著網站的系統越來越龐大時,以Web表單為開發中心的ASP.NET在開發上以及維護上將會是一個很重的負擔。首先,若你習慣將資料庫查詢的語言放在放在button_Cick的事件裡面,然後透過SqlClient內的物件將資料從資料庫取回並顯示在網頁上,雖然看起來這樣的流程以及設計上沒有甚麼不對,不過當系統越來越複雜時會發程式變得很攏長也不好閱讀,所以就有許多方法論以及架構陸陸續續的提出,來改善並解決系統開發上的一些問題,當中最常用於解決大型系統架構的方案就非MVC(Model-View-Controller)莫屬了。

1. MVC的架構:

MVC最早是由一位美國教授Trygve Reenskaug在1979年所提出的一個軟體架構模型,最早被應用在SmallTalk-80環境中,它提供了一個良好的設計架構,可以將我們在程式碼中關於介面設計部分、商業邏輯(Business Logic)和資料儲存清楚的切割出來,然而這種切割的方式可以為我們程式設計人員帶來許多好處,例如可以讓我們更容易的開發應用系統,並使後續對程式的修改和擴展簡化,也可以讓程式提高重複利用的可能性。 然而MVC他將應用程式切分為三個主要的區段:模型、視圖、控制器

 
  • 模型(Model):資料模型主要是將我們開發的系統中,所存取到相關的實體資料檔或是資料庫資料進行一種封裝的動作,在我們的系統內只需要對此模型進行操作或修改資料,等確認修改完成後再透過此模型將資料寫回到資料庫內,而不需要每次都透過我們的程式直接存取資料庫裡的資料。例如我們有一個資料表叫做客戶基本資料表,那我們就會建立一個Customer的類別,並定義許多的Property用來表示資料表的所有欄位,讓資料可以存放到這些Property,這個類別就是我們所稱的Model。
  • 視圖(View):簡單來說他就是我們一般常看到的使用者介面,讓使用者可透過介面來輸入或是操作此系統,例如會員註冊介面、訂單介面,而介面中都會有需要我們輸入資料的欄位,這些資料就會就儲存在我們定義好的模型中,當要編輯時再從模型裡面將資料取出並顯示在我們的介面上,在MVC中,視圖只是用來將我們模型裡的資料呈現出來而已。
  • 控制器(Controller):控制器它主要的目的是用來接收使用者介面所發出的請求,並依據請求來執行我們所設計好的商業邏輯或是修改模型資料等,當這些動作都處理完後,控制器就會依據處理完的結果來選擇對應的視圖將修改好的模型呈現出來。
圖  MVC架構圖

在MVC模式中使用者會透過介面來操作系統,所以當他按下一個按鈕或是觸發某一個動作時,這時候就會藉由Controller來將我們的Model進行狀態的改變,然後選擇對應的View來呈現UI的部分,這時候View會將剛剛被Controller修改過的Model呈現到使用者的面前。

2. MVC的優缺點:

相信大家都知道一件事情,在怎麼好的東西一定也有它的優點及缺點,下面我們就來看看MVC這種架構的優點以及缺點吧! 優點

  • 程式碼的重複使用性:相信大家都有過這樣的經驗,在開發一個系統或是應用程式時,會發現明明同樣的程式邏輯卻在許多地方又重寫一次,造成時間上的浪費也增加日後維護的困難性,所以MVC將我們的商業邏輯部份分離出來,可以提高程式碼的再利用性,並簡化我們設計上的難度。
  • 提高程式碼的維護性:由於我們將使用者介面、資料存取層以及商業邏輯清楚的切割出來,若今天想把原先的MySql移植到SQL Server上或是修改了資料表欄位,這時也只需要將Model作修改,而View就能正確的顯視訊息,並不會因為修改了某段程式而牽一髮動全身。
  • 利於團隊開發:當系統愈來越大時,相對來說就會投入越多的人力去開發,這時候每個人的分工角色就會是一個重點,若每個人都只各做個的而沒有一個標準的模式,之後要進行系統整合時就會變得很困難,若團隊的每個人可以遵循一個標準的方式,不管是彼此間的溝通或是功能之間的整合,都會有一套標準的方式來運行。

缺點

  • 運行效能降低
  • 架構複雜不利於小型的程式開發