常用的MVC變體有哪些

這篇文章給大家分享的是有關(guān)常用的MVC變體有哪些的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

MVC的變體

通過采用MVC模式，我們可以將可視化UI元素的呈現(xiàn)、UI處理邏輯和業(yè)務(wù)邏輯分別定義在View、Controller和Model中，但是對于三者之間的交互，MVC并沒有進(jìn)行嚴(yán)格的限制。最為典型的就是允許View和Model繞開Controller進(jìn)行直接交互，View可以通過調(diào)用Model獲取需要呈現(xiàn)給用戶的數(shù)據(jù)，Model也可以直接通知View讓其感知到狀態(tài)的變化。當(dāng)我們將MVC應(yīng)用于具體的項目開發(fā)中，不論是基于GUI的桌面應(yīng)用還是基于Web UI的Web應(yīng)用，如果不對Model、View和Controller之間的交互進(jìn)行更為嚴(yán)格的限制，我們編寫的程序可能比自治視圖更加難以維護(hù)。

今天我們將MVC視為一種模式（Pattern），但是作為MVC最初提出者的Trygve M. H. Reenskau卻將MVC視為一種范例（Paradigm），這可以從它在Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller (MVC)中對MVC的描述可以看出來：In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task.

模式和范例的區(qū)別在于前者可以直接應(yīng)用到具體的應(yīng)用上，而后者則僅僅提供一些基本的指導(dǎo)方針。在我看來MVC是一個很寬泛的概念，任何基于Model、View和Controller對UI應(yīng)用進(jìn)行分解的設(shè)計都可以成為MVC。當(dāng)我們采用MVC的思想來設(shè)計UI應(yīng)用的時候，應(yīng)該根據(jù)開發(fā)框架（比如Windows Forms、WPF和Web Forms）的特點(diǎn)對Model、View和Controller的界限以及相互之間的交互設(shè)置一個更為嚴(yán)格的規(guī)則。

在軟件設(shè)計的發(fā)展歷程中出現(xiàn)了一些MVC的變體（Varation），它們遵循定義在MVC中的基本原則，我們現(xiàn)在來簡單地討論一些常用的MVC變體。

MVP

MVP是一種廣泛使用的UI架構(gòu)模式，適用于基于事件驅(qū)動的應(yīng)用框架，比如ASP.NET Web Forms和Windows Forms應(yīng)用。MVP中的M和V分別對應(yīng)于MVC的Model和View，而P（Presenter）則自然代替了MVC中的Controller。但是MVP并非僅僅體現(xiàn)在從Controller到Presenter的轉(zhuǎn)換，更多地體現(xiàn)在Model、View和Presenter之間的交互上。

MVC模式中元素之間“混亂”的交互主要體現(xiàn)在允許View和Model繞開Controller進(jìn)行單獨(dú)“交流”，這在MVP模式中得到了徹底解決。如圖1-2所示，能夠與Model直接進(jìn)行交互的僅限于Presenter，View只能通過Presenter間接地調(diào)用Model。Model的獨(dú)立性在這里得到了真正的體現(xiàn)，它不僅僅與可視化元素的呈現(xiàn)（View）無關(guān)，與UI處理邏輯（Presenter）也無關(guān)。使用MVP的應(yīng)用是用戶驅(qū)動的而非Model驅(qū)動的，所以Model不需要主動通知View以提醒狀態(tài)發(fā)生了改變。

圖1-2  Model-View-Presenter之間的交互

MVP不僅僅避免了View和Model之間的耦合，更進(jìn)一步地降低了Presenter對View的依賴。如圖1-2所示，Presenter依賴的是一個抽象化的View，即View實現(xiàn)的接口IView，這帶來的最直接的好處就是使定義在Presenter中的UI處理邏輯變得易于測試。由于Presenter對View的依賴行為定義在接口IView中，我們只需要Mock一個實現(xiàn)了該接口的View就能對Presenter進(jìn)行測試。

構(gòu)成MVP三要素之間的交互體現(xiàn)在兩個方面，即View/Presenter和Presenter/Model。Presenter和Model之間的交互很清晰，僅僅體現(xiàn)在Presenter對Model的單向調(diào)用。而View和Presenter之間該采用怎樣的交互方式是整個MVP的核心，MVP針對關(guān)注點(diǎn)分離的初衷能否體現(xiàn)在具體的應(yīng)用中很大程度上取決于兩者之間的交互方式是否正確。按照View和Presenter之間的交互方式以及View本身的職責(zé)范圍，Martin Folwer將MVP可分為PV（Passive View）和SC（Supervising Controller）兩種模式。

PV與SC

解決View難以測試的最好的辦法就是讓它無需測試，如果View不需要測試，其先決條件就是讓它盡可能不涉及到UI處理邏輯，這就是PV模式目的所在。顧名思義，PV（Passive View）是一個被動的View，包含其中的針對UI元素（比如控件）的操作不是由View自身主動來控制，而被動地交給Presenter來操控。

如果我們純粹地采用PV模式來設(shè)計View，意味著我們需要將View中的UI元素通過屬性的形式暴露出來。具體來說，當(dāng)我們在為View定義接口的時候，需要定義基于UI元素的屬性使Presenter可以對View進(jìn)行細(xì)粒度操作，但這并不意味著我們直接將View上的控件暴露出來。舉個簡單的例子，假設(shè)我們開發(fā)的HR系統(tǒng)中具有如圖1-3所示的一個Web頁面，我們通過它可以獲取某個部門的員工列表。

圖1-3  員工查詢頁面

現(xiàn)在通過ASP.NET Web Forms應(yīng)用來設(shè)計這個頁面，我們來討論一下如果采用PV模式，View的接口該如何定義。對于Presenter來說，View供它操作的控件有兩個，一個是包含所有部門列表的DropDownList，另一個則是顯示員工列表的GridView。在頁面加載的時候，Presenter將部門列表綁定在DropDownList上，與此同時包含所有員工的列表被綁定到GridView。當(dāng)用戶選擇某個部門并點(diǎn)擊“查詢”按鈕后，View將包含篩選部門在內(nèi)的查詢請求轉(zhuǎn)發(fā)給Presenter，后者篩選出相應(yīng)的員工列表之后將其綁定到GridView。

如果我們?yōu)樵揤iew定義一個接口IEmployeeSearchView，我們不能按照所示的代碼將上述這兩個控件直接以屬性的形式暴露出來。針對具體控件類型的數(shù)據(jù)綁定屬于View的內(nèi)部細(xì)節(jié)（比如說針對部門列表的顯示，我們可以選擇DropDownList也可以選擇ListBox），不能體現(xiàn)在表示用于抽象View的接口中。另外，理想情況下定義在Presenter中的UI處理邏輯應(yīng)該是與具體的技術(shù)平臺無關(guān)的，如果在接口中涉及控件類型，這無疑將Presenter也與具體的技術(shù)平臺綁定在了一起。

public interface IEmployeeSearchView

{

    DropDownList             Departments { get;}

    GridView                 Employees { get; }

}

正確的接口和實現(xiàn)該接口的View（一個Web頁面）應(yīng)該采用如下的定義方式。Presenter通過對屬性Departments和Employees賦值進(jìn)而實現(xiàn)對相應(yīng)DropDownList和GridView的數(shù)據(jù)綁定，通過屬性SelectedDepartment得到用戶選擇的篩選部門。為了盡可能讓接口只暴露必需的信息，我們特意將對屬性的讀/寫作了控制。

public interface IEmployeeSearchView

{

    IEnumerable<string>        Departments { set; }

    string                     SelectedDepartment { get; }

    IEnumerable<Employee>          Employees { set; }

}

public partial class EmployeeSearchView: Page, IEmployeeSearchView

{

    //其他成員

    public IEnumerable<string> Departments

    {

        set

        {

            this.DropDownListDepartments.DataSource = value;

            this.DropDownListDepartments.DataBind();

        }

    }

    public string SelectedDepartment

    {

        get { return this.DropDownListDepartments.SelectedValue;}

    }

    public IEnumerable<Employee> Employees

    {          

        set

        {

            this.GridViewEmployees.DataSource = value;

            this.GridViewEmployees.DataBind();

        }

    }

}

PV模式將所有的UI處理邏輯全部定義在Presenter上，意味著所有的UI處理邏輯都可以被測試，所以從可測試性的角度來這是一種不錯的選擇，但是它要求將View中可供操作的UI元素定義在對應(yīng)的接口中，對于一些復(fù)雜的富客戶端（Rich Client）View來說，接口成員將會變得很多，這無疑會提升編程所需的代碼量。從另一方面來看，由于Presenter需要在控件級別對View進(jìn)行細(xì)粒度的控制，這無疑會提供Presenter本身的復(fù)雜度，往往會使原本簡單的邏輯復(fù)雜化，在這種情況下我們往往采用SC模式。

在SC模式下，為了降低Presenter的復(fù)雜度，我們將諸如數(shù)據(jù)綁定和格式化這樣簡單的UI處理邏輯轉(zhuǎn)移到View中，這些處理邏輯會體現(xiàn)在View實現(xiàn)的接口中。盡管View從Presenter中接管了部分UI處理邏輯，但是Presenter依然是整個三角關(guān)系的驅(qū)動者，View被動的地位依然沒有改變。對于用戶作用在View上的交互操作，View本身并不進(jìn)行響應(yīng)，而是直接將交互請求轉(zhuǎn)發(fā)給Presenter，后者在獨(dú)立完成相應(yīng)的處理流程（可能涉及針對Model的調(diào)用）之后會驅(qū)動View或者創(chuàng)建新的View作為對用戶交互操作的響應(yīng)。

View和Presenter交互的規(guī)則（針對SC模式）

View和Presenter之間的交互是整個MVP的核心，能否正確地應(yīng)用MVP模式來架構(gòu)我們的應(yīng)用主要取決于能否正確地處理View和Presenter兩者之間的關(guān)系。在由Model、View和Presenter組成的三角關(guān)系中，核心不是View而是Presenter，Presenter不是View調(diào)用Model的中介，而是最終決定如何響應(yīng)用戶交互行為的決策者。

打個比方，View是Presenter委派到前端的客戶代理，而作為客戶的自然就是最終的用戶。對于以鼠標(biāo)/鍵盤操作體現(xiàn)的交互請求應(yīng)該如何處理，作為代理的View并沒有決策權(quán)，所以它會將請求匯報給委托人Presenter。View向Presenter發(fā)送用戶交互請求應(yīng)該采用這樣的口吻：“我現(xiàn)在將用戶交互請求發(fā)送給你，你看著辦，需要我的時候我會協(xié)助你”，而不應(yīng)該是這樣：“我現(xiàn)在處理用戶交互請求了，我知道該怎么辦，但是我需要你的支持，因為實現(xiàn)業(yè)務(wù)邏輯的Model只信任你”。

對于Presenter處理用戶交互請求的流程，如果中間環(huán)節(jié)需要涉及到Model，它會直接發(fā)起對Model的調(diào)用。如果需要View的參與（比如需要將Model最新的狀態(tài)反應(yīng)在View上），Presenter會驅(qū)動View完成相應(yīng)的工作。

對于綁定到View上的數(shù)據(jù)，不應(yīng)該是View從Presenter上“拉”回來的，應(yīng)該是Presenter主動“推”給View的。從消息流（或者消息交換模式）的角度來講，不論是View向Presenter完成針對用戶交互請求的通知，還是Presenter在進(jìn)行交互請求處理過程中驅(qū)動View完成相應(yīng)的UI操作，都是單向（One-Way）的。反應(yīng)在應(yīng)用編程接口的定義上就意味著不論是定義在Presenter中被View調(diào)用的方法，還是定義在IView接口中被Presenter調(diào)用的方法最好都沒有返回值。如果不采用方法調(diào)用的形式，我們也可以通過事件注冊的方式實現(xiàn)View和Presenter的交互，事件機(jī)制體現(xiàn)的消息流無疑是單向的。

View本身僅僅實現(xiàn)單純的、獨(dú)立的UI處理邏輯，它處理的數(shù)據(jù)應(yīng)該是Presenter實時推送給它的，所以View盡可能不維護(hù)數(shù)據(jù)狀態(tài)。定義在IView的接口最好只包含方法，而避免屬性的定義，Presenter所需的關(guān)于View的狀態(tài)應(yīng)該在接收到View發(fā)送的用戶交互請求的時候一次得到，而不需要通過View的屬性去獲取。

實例演示：SC模式的應(yīng)用（S101）

為了讓讀者對MVP模式，尤其是該模式下的View和Presenter之間的交互方式有一個深刻的認(rèn)識，我們現(xiàn)在來做一個簡單的實例演示。本實例采用上面提及的關(guān)于員工查詢的場景，并且采用ASP.NET Web Forms來建立這個簡單的應(yīng)用，最終呈現(xiàn)出來的效果如圖1-3所示。前面我們已經(jīng)演示了采用PV模式下的IView應(yīng)該如何定義，現(xiàn)在我們來看看SC模式下的IView有何不同。

先來看看表示員工信息的數(shù)據(jù)類型如何定義。我們通過具有如下定義的數(shù)據(jù)類型Employee來表示一個員工。簡單起見，我們僅僅定義了表示員工基本信息（ID、姓名、性別、出生日期和部門）的5個屬性。

public class Employee

{

    public string        Id { get; private set; }

    public string        Name { get; private set; }

    public string        Gender { get; private set; }

    public DateTime     BirthDate { get; private set; }

    public string        Department { get; private set; }

    public Employee(string id, string name, string gender,

        DateTime birthDate, string department)

    { 

        this.Id         = id;

        this.Name            = name;

        this.Gender     = gender;

        this.BirthDate       = birthDate;

        this.Department   = department;

    }

}

作為包含應(yīng)用狀態(tài)和狀態(tài)操作行為的Model通過如下一個簡單的EmployeeRepository類型來體現(xiàn)。如代碼所示，表示所有員工列表的數(shù)據(jù)通過一個靜態(tài)字段來維護(hù)，而GetEmployees返回指定部門的員工列表，如果沒有指定篩選部門或者指定的部門字符為空，則直接返回所有的員工列表。

public class EmployeeRepository

{

    private static IList<Employee> employees;

    static EmployeeRepository()

    {

        employees = new List<Employee>();

        employees.Add(new Employee("001", "張三", "男",

            new DateTime(1981, 8, 24), "銷售部"));

        employees.Add(new Employee("002", "李四", "女",

            new DateTime(1982, 7, 10), "人事部"));

        employees.Add(new Employee("003", "王五", "男",

            new DateTime(1981, 9, 21), "人事部"));

    }

    public IEnumerable<Employee> GetEmployees(string department = "")

    {

        if (string.IsNullOrEmpty(department))

        {

            return employees;

        }

        return employees.Where(e => e.Department == department).ToArray();

    }

}

接下來我們來看作為View接口的IEmployeeSearchView的定義。如下面的代碼片段所示，該接口定義了BindEmployees和BindDepartments兩個方法，分別用于綁定基于部門列表的DropDownList和基于員工列表的GridView。除此之外，IEmployeeSearchView接口還定義了一個事件DepartmentSelected，該事件會在用戶選擇了篩選部門后點(diǎn)擊“查詢”按鈕時觸發(fā)。DepartmentSelected事件參數(shù)類型為自定義的DepartmentSelectedEventArgs，屬性Department表示用戶選擇的部門。

public interface IEmployeeSearchView

{

    void     BindEmployees(IEnumerable<Employee> employees);

    void     BindDepartments(IEnumerable<string> departments);

    event    EventHandler<DepartmentSelectedEventArgs> DepartmentSelected;

}

public class DepartmentSelectedEventArgs : EventArgs

{

    public string Department { get; private set; }

    public DepartmentSelectedEventArgs(string department)

    {

        this.Department = department;

    }

}

作為MVP三角關(guān)系核心的Presenter通過EmployeeSearchPresenter表示。如下面的代碼片段所示，表示View的只讀屬性類型為IEmployeeSearchView接口，而另一個只讀屬性Repository則表示作為Model的EmployeeRepository對象，兩個屬性均在構(gòu)造函數(shù)中初始化。

public class EmployeeSearchPresenter

{

    public IemployeeSearchView View { get; private set; }

    public EmployeeRepository    Repository { get; private set; }

    public EmployeeSearchPresenter(IEmployeeSearchView view)

    {

        this.View                        = view;

        this.Repository              = new EmployeeRepository();

        this.View.DepartmentSelected += OnDepartmentSelected;

    }

    public void Initialize()

    {

        IEnumerable<Employee> employees = this.Repository.GetEmployees();

        this.View.BindEmployees(employees);

        string[] departments =

            new string[] { "銷售部", "采購部", "人事部", "IT部" };

        this.View.BindDepartments(departments);

    }

    protected void OnDepartmentSelected(object sender,

        DepartmentSelectedEventArgs args)

    {

        string department        = args.Department;

        var employees            = this.Repository.GetEmployees(department);

        this.View.BindEmployees(employees);

    }

}

在構(gòu)造函數(shù)中我們注冊了View的DepartmentSelected事件，作為事件處理器的OnDepartmentSelected方法通過調(diào)用Repository（即Model）得到了用戶選擇部門下的員工列表，返回的員工列表通過調(diào)用View的BindEmployees方法實現(xiàn)了在View上的數(shù)據(jù)綁定。在Initialize方法中，我們通過調(diào)用Repository獲取所有員工的列表，并通過View的BindEmployees方法顯示在界面上。作為篩選條件的部門列表通過調(diào)用View的BindDepartments方法綁定在View上。

最后我們來看看作為View的Web頁面如何定義。如下所示的是作為頁面主體部分的HTML，核心部分是一個用于綁定篩選部門列表的DropDownList和一個綁定員工列表的GridView。

<html xmlns="http://www.w3.org/1999/xhtml">

    <head>

        <title>員工管理</title>

        <link rel="stylesheet" href="Style.css" />

    </head>

    <body>

        <form id="form1" runat="server">

            <div id="page">

                <div class="top">

                    選擇查詢部門：

                    <asp:DropDownList ID="DropDownListDepartments"

                        runat="server" />

                    <asp:Button ID="ButtonSearch" runat="server" Text="查詢"

                        OnClick="ButtonSearch_Click" />

                </div>

                <asp:GridView ID="GridViewEmployees" runat="server"

                    AutoGenerateColumns="false" Width="100%">

                    <Columns>

                        <asp:BoundField DataField="Name" HeaderText="姓名" />

                        <asp:BoundField DataField="Gender" HeaderText="性別" />

                        <asp:BoundField DataField="BirthDate"

                            HeaderText="出生日期"

                            DataFormatString="{0:dd/MM/yyyy}" />

                        <asp:BoundField DataField="Department" HeaderText="部門"/>

                    </Columns>

                </asp:GridView>

            </div>

        </form>

    </body>

</html>

如下所示的是該Web頁面的后臺代碼的定義，它實現(xiàn)了定義在IEmployeeSearchView接口的兩個方法（BindEmployees和BindDepartments）和一個事件（DepartmentSelected）。表示Presenter的同名只讀屬性在構(gòu)造函數(shù)中被初始化。在頁面加載的時候（Page_Load方法）Presenter的Initialize方法被調(diào)用，而在“查詢”按鈕被點(diǎn)擊的時候（ButtonSearch_Click）事件DepartmentSelected被觸發(fā)。

public partial class Default : Page, IEmployeeSearchView

{

    public EmployeeSearchPresenter Presenter { get; private set; }

    public event EventHandler<DepartmentSelectedEventArgs> DepartmentSelected;

    public Default()

    {

        this.Presenter = new EmployeeSearchPresenter(this);

    }

    protected void Page_Load(object sender, EventArgs e)

    {

        if (!this.IsPostBack)

        {

            this.Presenter.Initialize();

        }

    }

    protected void ButtonSearch_Click(object sender, EventArgs e)

    {

        string department = this.DropDownListDepartments.SelectedValue;

        DepartmentSelectedEventArgs eventArgs =

            new DepartmentSelectedEventArgs(department);

        if (null != DepartmentSelected)

        {

            DepartmentSelected(this, eventArgs);

        }

    }

    public void BindEmployees(IEnumerable<Employee> employees)

    {

        this.GridViewEmployees.DataSource = employees;

        this.GridViewEmployees.DataBind();

    }

    public void BindDepartments(IEnumerable<string> departments)

    {

        this.DropDownListDepartments.DataSource = departments;

        this.DropDownListDepartments.DataBind();

    }

}

感謝各位的閱讀！關(guān)于“常用的MVC變體有哪些”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！