|
|
我们总会有这样一个经验：一个系统最不容易也最不应该变化的部分是领域逻辑，最容易变化也最应该变化的是数据的呈现方式。
在Java的各种应用中可以说是到处可见mvc，j2ee贯穿mvc的概念，Android的开发方式也是类mvc的，mvc结构对于做过Java应用的人而言简直就是司空见惯。而在.NET这边，由于之前微软为大家提供的各种winform、ASP.NET项目典范（比如那个petshop series）将“三层”概念很好的灌输到了.NET程序员的大脑中，许多.NET开发者凡是做个东西都要搬出自己最拿手的IModel、IDAL这样的神器。
其实mvc与所谓的“三层架构”是两个层次上的东西，前者是一种结构模式，而后者则是分层的角度去说。
一件很奇怪的事情，许多人知道“三层”却不知道mvc，其实这要归结与.NET的早期开发技术ASP.NET和winform这些page controller的典范让许多人对三层夸夸其谈却对mvc视而不见甚至一无所知。什么是page controller模式呢？搞.NET的大多都用过winform和webform，这种xxxform用起来很直观，我们想要做一个程序，ok，最简单的方式就是拖拖拽拽几个控件，然后在一个叫code behind的东西里写这些UI事件的处理逻辑，加一大堆变量用于记录数据和状态，这样一个程序就能出炉。这种开发方式对于一些小软件系统的开发其实效率还是蛮高的，后来人们看到其弊端---一旦修改UI，事件处理就要跟着变，但是业务还是那个业务，凭什么要修改非UI的代码？于是有人提出“三层”，最朴素的理解就是将原本那堆事件处理里的code分成业务代码和数据库访问代码并转移到其它类中，做多了就把那坨UI叫做UI，那坨业务代码叫做BLL，那坨DAO叫做DAL。也就是这种架构：
而对于j2ee的开发者来说熟悉的是下图。
MVC是什么
MVC是一个很经典的结构，并且其又其思想衍生出很多变种比如MVP,MVVP。传统的MVC结构之一是这样的（拿主动型mvc来说）：
比如web开发（比如ASP.NET mvc或者是Java的web开发方式）,view就是纯web页面或者webservice，当提交一个表单/调用webservice或者ajax后会将数据提交给controller（当然期间可能会经过各种filterchain、listener这样的东西）controller调用相应的业务模块来处理这个请求，最终结果会更新View的显示。
MVP
对于非天然mvc的框架
对于ASP.NET/winform而言，虽然可以通过改造让其支持mvc结构的开发（比如通过定制IHttpModule、IHttpHandler云云），但是在企业看来这些都算是邪门武功（因为这样会丧失xxxform在开发上的很多特性比如快速开发）。大多数使用的是mvp模式。什么是mvp呢？其实mvp是mvc的一个变种。因为用winform或者webform的话form始终是个阻碍mvc开发的问题。那么好，我们仍然使用designer和codebehind，其实一个架构设计的好坏是取决于人而不是具体的技术的，只要我们OO一时强page controller一样好用。
在MVP模式中我们需要自己定制各个View（web页面或者窗体）对应的IView和IPresenter、IModel。IView要对IPresenter暴露操作UI、数据绑定的接口，IPresenter对IView要暴露当UI事件触发需要调用的接口，IPresenter根据IView传递过来的请求调用业务接口并根据结果操作UI。举个简单的例子，一个计算“x+y=?”的程序。如果我们这样定义IPresenter和IView
public interface IPresenter
{
IView View { get; set; }
void CalculateResult();
}
public interface IView
{
IPresenter Presenter { get; set; }
void ShowResult(string result);
int ValueOne { get; }
int ValueTwo { get; }
}
NET技术：谈.net开发人员应该熟悉的开发模式，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
