[MVCSharp]MVC# Overview概述

MVC# Overview概述

Abstract: This article gives an overview of MVC# - a Model-View-Presenter framework for .NET platform. It firstly explains the MVP pattern essentials and then walks through the key features of the MVC# framework which help building true MVP-based solutions.

MVC#概述，.Net平臺的MVP框架。首先介紹MVP模式的必要性，接着簡要介紹MVC#的關鍵要素，助力基於MVP模式的解決方案構建。

What is Model-View-Presenter? 什麼是MVP
    3-tier architecture 三層架構
    MVC and MVP patterns MVC和MVP
Why using MVC#? 如何使用MVC#
    1. Views and controllers get connected automatically 視圖和控制器自動鏈接
    2. Multiple GUI platforms supported 多種GUI平臺支持
    3. Platform-independent navigation to views 平臺獨立的視圖導航
    4. Tasks concept 任務的概念
Conclusion 結論

What is Model-View-Presenter?什麼是MVP？

3-tier architecture三層架構

One of the most fundamental approaches in software engineering is the Layered architecture. It implies dividing a system into several interacting layers with certain limitations imposed on how layers may interact.s Layered architecture finds its application in various systems for example net protocols (TCP/IP layers), operating systems (three layers: core, drivers, applications) and others.

軟件工程中一個最重要的方法就是分層架構。

A particular case of layered architecture is the 3-tier architecture with its variations: Model-View-Controller and Model-View-Presenter. Before considering MVP (and MVC) let us discuss the general 3-tier architecture and its difference to the conventional programming style.

一個特別的架構模式就是三層架構和他的不一樣表現形式：MVC和MVP.在考慮MVP或者MVC以前咱們先討論普通的三層架構和傳統編程形式的區別。

A straightforward (and widely used) approach in designing applications is the 2-tier architecture. According to it an application consists of a presentation layer and a domain layer. Domain layer classes represent the problem domain entities (e.g. customer, order) and are usually bound to some database access facilities. Presentation classes in 2-tier architecture have the following responsibilities:

• receive user input接受用戶輸入
• make necessary calls to the domain tier 必要的調用
• decide what to show next to the user 肯定下面展現給用戶什麼
• display output 顯示輸出

These responsibilities are rather vast and, as a system grows, may result in a bloated presentation layer. Moreover they logically can be divided into two groups: actually presentation logic (code for perceiving input and displaying output) and application logic (communication with the domain tier and application flow decisions). These responsibilities require different programming skills and should better be not mixed in a single module/class. A quite natural solution is to split this too broad presentation layer into two: presentation and application logic:

3-tier architecture is rather abstract. While it declares an existence of three layers, it says nothing about classes in these layers and their interaction. A much more precise form have two 3-tier architecture variations: Model-View-Controller and Model-View-Presenter. Let us proceed to their discussion.

MVC and MVP patterns MVC和MVP模式

According to both MVC and MVP the presentation layer consists of view objects, and application logic consists of controller objects (we will use "controller" name instead of "presenter" in MVP). For each view object a corresponding controller exists and vice versa. And although MVC and MVP are based on a common 3-tier principle: views process only presentation needs and controllers handle application logic, these patterns have two major differences:

在MVC和MVP中表現層包括視圖對象。應用層包括控制器對象（使用控制器代替表示器）。每一個視圖對象對應一個控制器。儘管MVC和MVP基於一樣的三層準則：視圖只負責表現，控制器處理應用邏輯，這兩個模式有兩個主要的區別：

1. In MVC controllers receive and process user input, but in MVP views receive user input and then merely delegate processing to the corresponding controllers. That is why MVP pattern better fits modern UI environments (Windows/Web forms) where view classes themselves handle user gestures.

在MVC中控制器接收和處理用戶輸入，在MVP中視圖接受用戶輸入接着委託給相應的控制器處理。這是爲何MVP模式更適合如今的UI環境（Window/Web Forms），視圖類自身處理用戶的手勢。

2. In MVC controllers affect their views by changing the intermediate presentation model, which the views are subscribed to (by observer pattern). This makes views pure observers without direct access to them. MVP on the other hand violates this "pure observer" rule by providing a direct link from a controller to its view. This makes MVP more handy as compared to MVC.

在MVC中，控制器影響他們的視圖是經過改變視圖訂閱的中間媒介表現模型來實現的（根據觀察者模式）。這使得視圖成爲純觀察者而不能直接接觸控制器。而另外一方面，MVP則侵犯了純觀察者經過直接提供控制器的引用。這使得MVP比MVC更具處理性。

備註：PresentationModel表明了presentation（可視化界面，或者成爲視圖）的狀態和行爲，而且是徹底獨立於界面中使用的GUI控件的…… Presentation Model把視圖（View）的狀態和行爲抽取到model類中，仍然屬於presentation層。 Presentation Model要與domain層協同，爲視圖提供接口，來最小化在view中須要作的決定。視圖（view）或者把狀態存儲到Presentation Model中，或者頻繁的與Presentation Model同步狀態。

The said differences make the MVP pattern more attractive than MVC from the developer's point of view. And indeed MVP was designed to be an evolution of MVC and to improve the latter. That is why we often refer to MVP as "sharp MVC" and therefore the name our MVP framework is MVC#.

所述的不一樣從觀察者的角度使MVP比MVC更具吸引力。事實上MVP被設計來發展MVC。這使咱們爲啥稱MVP爲Sharp MVC 的緣由，也是咱們的MVP框架稱爲MVC# 的緣由。

Why using MVC#?

Now that we are convinced in the usefulness of the MVP pattern we may start using it in our applications. However it may be not as easy. Maintaining an additional application logic layer may require considerable efforts. For example a developer needs to take care of linking between all views and appropriate controllers,

Fortunately MVC# automates and takes on itself much of the work concerned with MVP usage. Thus it simplifies and speeds up the development of MVP applications. Below is the list of MVC# framework features:

1. Views and controllers get connected automatically

Developers do not have to care about associating views with their controllers. MVC# framework automatically establishes links between views and corresponding controllers:

開發者沒必要關心視圖和控制器的關聯。MVC# 框架自動實現視圖和相應的控制器的鏈接。

publicclass OrderDetailsView

    ...

    privatevoid processOrderButton_Click(object sender, EventArgs e)

    {

        // No code needed to establish a link to the controller

        (Controller as OrderDetailsController).ProcessOrder();

    }

2. Multiple GUI platforms supported

MVC# allows targeting different GUI platforms (Windows, Web, Silverlight, etc.) Thus the same application can be used with quite different presentation layers - one for Windows, the other for Silverlight or Web environment, etc.:

3. Platform-independent navigation to views 平臺無關導航到視圖。

To make application logic fully independent of the presentation layer, MVC# provides a platform-independent way of navigating to views. Instead of  activating a Windows form or redirecting to a Web page a developer should simply call a uniform Navigator.Navigate(...) method:

爲了使應用邏輯徹底獨立於表現層，MVC# 提供了一個平臺無關的導航到視圖的方法。不管是激活Windows窗體仍是導航到WebPage只要經過調用Navigator.Navigate(...)方法。

publicclass OrderDetailsController

    ...

    publicvoid ProcessOrder()

    {

        // No Response.Redirect(...) or Form.Show() calls

        Task.Navigator.Navigate(OrderSupportTask.ProcessOrder);

    }

4. Tasks concept任務的概念

Another useful feature of MVC# framework, although not directly related to the MVP pattern, is the Task concept. A task unites several views with their controllers in fulfilling some job. For example a ticket booking task may consist of two views: one to choose a ticket, the other - to do the payment. In MVC# all controllers within a task are given a link to the task object. Generally a task can be expressed as a workflow or a state machine.

另一個有用的MVC#元素是任務的概念，儘管不是直接關係到MVP模式。一個任務包括多個視圖和它們的控制器來完成一些工做。例如購票任務可能包括兩個視圖，一個是選票，一個是付款。在MVC#，全部的在一個任務中的控制器，同時指向任務對象。通常地，一個任務能夠被表述爲一個工做流或者狀態機。

 

Conclusion

MVC# framework frees developers from much of extra work required in construction of Model-View-Presenter applications. It allows creating flexible MVP-based application with almost no extra cost. For more information on MVC# including the examples of using it see the project web site.