雖然接觸了兩者有一段時間了，但是有時還是會混淆概念，在此處不打算說明二者的區別，因為二者都是架構模式，並且也有一定的共存度，在實際開發中，嚴格區分意義不大。基於最近涉及到這部分知識就在複習下，編程過程中，基礎概念更重要，而不是技術。 先看看，三層架構吧，即UI（表示層），BLL（業務邏輯層），DAL ...
雖然接觸了兩者有一段時間了，但是有時還是會混淆概念，在此處不打算說明二者的區別，因為二者都是架構模式，並且也有一定的共存度，在實際開發中，嚴格區分意義不大。基於最近涉及到這部分知識就在複習下，編程過程中，基礎概念更重要，而不是技術。
先看看，三層架構吧，即UI（表示層），BLL（業務邏輯層），DAL(數據訪問層)：
UI(表現層):主要是指與用戶交互的界面。用於接收用戶輸入的數據和顯示處理後用戶需要的數據。
BLL:(業務邏輯層):UI層和DAL層之間的橋梁。實現業務邏輯。業務邏輯具體包含：驗證、計算、業務規則等等。
DAL:(數據訪問層):與資料庫打交道。主要實現對數據的增、刪、改、查。將存儲在資料庫中的數據提交給業務層，同時將業務層處理的數據保存到資料庫。（當然這些操作都是基於UI層的。用戶的需求反映給界面（UI），UI反映給BLL，BLL反映給DAL，DAL進行數據的操作，操作後再一一返回，直到將用戶所需數據反饋給用戶）
其實，真正使用過三層架構的都知道，三者之間是通過Entity傳遞數據的，Entity貫穿三層，將三者連接起來，同時也實現了對數據實體的封裝，取代了個層之間多變數的數據傳遞(數據交流)，大大的簡化了數據交流，也降低了數據發生錯誤的概率。（Entity其實就是對資料庫表實體的封裝），Entity與三層之間的依賴關係：
再看MVC架構，即M（model 模型·）,V（view 視圖）,C（controller 控制器）三個部分。在MVC架構中這三部分是必須的，但我們也可以根據項目的實際需求與實際情況還能再增加，比如實現Service層或Repository層等，我們可以自行擴展，大幅提高了開發時的靈活性。
Model（數據模型）:用於封裝與應用程式在商業邏輯上相關的數據，以及對其數據操作的處理方法(資料庫的訪問操作，即增刪改查；數據結構的定義；數據格式的驗證)。Model並不依賴於View和Controller，也就是說Model並不需要知道它會如何被顯示出來或如何被應用，只需要專註於自己該有的責任即可。Model中常見的技術有Entity Framework（即EF）、NHibernate、LINQ to SQL、Typed DataSet和ADO.NET等。
View（視圖）: 頁面顯示或獲取用戶輸入，View需要負責將Controller傳過來的數據配合“顯示邏輯”呈現給用戶，此處雖然View需要Contorller傳遞數據，但是View並沒有依賴某個Controller,任何Controller只要能提供View所需要的數據，View就可以根據顯示邏輯將其顯示出來，是一種鬆散的關聯關係。
Controller（控制器）:屬於一種結果協調者的角色，因為M-V-C三個部分沒有直接的聯繫，View無法直接與Model溝通，即Model可以操作數據，View可以顯示數據，因此，VIew顯示的數據需由Controller從Model獲取後提供給View。即Controller的角色位於用戶介面層和商業邏輯層中間。
其中，MVC中最重要的特性是關註點分離和約定優於配置。關註點分離，簡單地說就是“只註意需要註意的”，這樣可以很好的解耦模塊，各個單元的複雜度就相對降低，更容易開發，同時，也增強了程式的可維護性。約定優於配置，簡單地說，就是開發過程中應該遵守的約定，如：Controller的文件名後面一定要以Controller結尾；View文件一定要放在VIews文件夾下；View的名稱就是對應的Controller的Action名稱；Web API的Action名稱前面應該加上HTTP動詞等等，這樣有利於項目的後期開發與維護，以防止因人員流動而使項目無其他人願意接手。
