理解MVC模式

模型（Model）:含有或表現用戶進行操作的數據，模型可以是簡單的視圖模型，他們只表現視圖和控制器之間的數據傳遞。也可以是域模型，包含業務領域的數據，以及處理這些數據的操作，轉換和規則。

視圖（View）：將模型的某些部分渲染成用戶界面

控制器（Controller）:處理傳入請求，執行模型操作，渲染給用戶視圖。

模型是程序工作的定義，不涉及UI也不涉及請求處理。

MVC架構的每一部分都有良好的定義和自包含，這稱為關註分離。

域模型

MVC最重要的部分是域模型，對於應用程序必須支持的業務或活動中存在的現實實體，操作，規則等。通過對他們進行標識的方法創建模型，稱為於模型（Domain）。

域模型一般是一組C#類（類，結構），統稱為域類型（Domain Type）。域的操作由域類型中的方法實現，域規則表示成這些方法的邏輯。或者通過C#的註解屬性實現。創建一個域類型的實例來表現特定的數據片段時，創建了域對象。域模型通常是持久化的，且一直處於活動狀態。最常見的實現方式是關系數據庫。

總結就是域模型是程序中業務數據及處理的唯一和權威的定義。

MVC的ASP.NET實現

其他模式

智能UI模式：主要是面向頁面的組件開發，組件比較智能，比如拖拽按鈕按鍵組件就可以直接設計出頁面。比較有名的是Winodws Form和ASP.NET Web Form。優點是開發快，上手容易，適合小項目。缺點是不易維護和拓展，沒有關註分離，業務和UI組合在一起，前段後端結合太緊密。

模型-視圖架構：相當於智能UI模式所有的地方都有可能有業務邏輯。模型視圖模式把業務邏輯抽取出來形成一個獨立的域模型。這種做法數據過程和規則都集中在一個單獨的部分中。但是問題是UI和模型仍然聯系的太緊密。模型通常有大量的數據訪問代碼。

三層架構：比模型視圖模式更進一步的優化是，從模型中抽取一層叫做數據訪問層（DAL）。三層架構是應用程序中使用最廣範的模式，提供了較好的分離而且不復雜。三層架構已經和MVC模式非常相像了，但是差別是UI層和模型之間仍然耦合太強。也就是說沒有完全分離。MVC模式是每層之間完全分離的。

松耦合組件

最理想的應用是每個組件都不了解其他組件，僅僅是通過抽象的結構和抽象類來處理其他組件。這種稱為松耦合。

實例：一個能夠發送郵件的組件MyEmialSender，一個通用的接口IEmailSender，一個具體的實現他組件如PasswordResetHelper用來重置密碼和發送郵件。

實現的代碼結構如下

    public class PasswordResetHelper
    {
        public void ResetPasswor() { 
            IEmailSender mySender=new MyEmailSender;
            mySender.SendEmail();
        }
    }
    public interface IEmailSender
    {
        void SendEmail();
    }
    public class MyEmailSender:IEmailSender
    {
        public void SendEmail()
        {
            //Send Emial
        }
    }

結構圖如下

問題：三個類和接口直接仍然緊密結合。

依賴註入控制反轉：一種方法，能夠直接獲取某個接口的對象，又不必創建該對象。

1：打斷聲明和使用依賴。接口的使用類PasswordResetHelper不再有MyEmailSender的任何知識，僅僅依賴了接口。也就是說不再了解接口的任何實現。

    public class PasswordResetHelper
    {
        private IEmailSender mySender;
public PasswordResetHelper(IEmailSender senderParam)
        {
            mySender = senderParam;
        }
        public void ResetPasswor() { 
            mySender.SendEmail();
        }
    }
    public interface IEmailSender
    {
        void SendEmail();
    }
    public class MyEmailSender:IEmailSender
    {
        public void SendEmail()
        {
            //Send Emial
        }
    }

2：註射依賴項

在創建PasswordResetHelper的實例時，註入聲明的依賴項，稱為依賴項註入。

這種依賴項是在運行時才被註入到該類中，也就是說在PasswordResetHelper實例期間才會創建IEmialSender接口的實例類實例，並傳遞給PasswordResetHelper構造器，PasswordResetHelper與依賴的接口實現之間不存在編譯依賴項。

3：依賴項註入容器

雖然實現類PasswordResetHelper已經實現了弱耦合，不需要在該類中定義接口實現，但是在其他地方仍然需要類似IEmialSender sender=new MyEmialSender()，然後有Helper=new PasswordResetHelper(sender)的語句。

依賴項註入容器（DI容器），他在實現類聲明的依賴項和解決依賴項類之間充當中間件角色。

這種容器的作用就是請求接口，返回接口的實現類，如請求IEmialSender，則返回MyEmailSender實例。這種容器的作用就是程序不再需要手動使用new關鍵字創建對象了。而且完全依賴DI容器。

現在已經有很多比較好的DI容器，如微軟的Unity。還有Ninject等。

四：MVC模式