行相应的处理。我们先来看看控制器的可能代码123456789101112131415161718192021/// summary/// 控制器类/// /summarypublicclassController{publicvoidAction(ActionType actionType){}}/// summary/// 控制器完成的动作/// /summarypublicenumActionType{Add,Delete,Query,Update}视图中的可能代码12345privatevoidbutton1_Click(objectsender, RoutedEventArgs e){Controller controller newController();controller.Action(ActionType.Add);}代码中的控制器可以是任何特定技术的视图控制器将会为视图中每个可能发生的操作提供一个专门的方法每个支持用户操作的动作都对应着一个与之相关的处理服务。视图负责数据的呈现控制器负责更新模型如果模型发生变化那么将会通过观察者模式通知视图其状态发生变化然后视图将会决定是否将模型的变化体现在视图上如果需要更新那么视图将会从模型中读取最新的数据信息。MVC中的模型我们上面罗列了几种可能如果说我们这里的模型是业务逻辑层的话那么我们就会直接调用业务逻辑对象中的方法完成模型状态的更新这些都是控制器来完成的如果说MVC中的模型是数据传输对象那么可能控制器将会通过业务逻辑层抽象出来的服务层的接口来访问与该数据传输对象相对应的公开方法去完成模型的操作。如果说我们这里的模型是业务模型那么控制器只是完成路由的功能先要解析动作的发出者然后要将这个动作解析交给哪个业务模型来处理转发完毕后就忘记了其他的就有业务模型自动完成。控制器有时候还要负责选择呈现视图的跳转功能如果需要跳转时那么控制器就会创建新的视图控制器模型。我们有时候可能想要通过全局配置的方式去完成重定向比如说通过XML文件去配置类似工作流那样的方式来做的话。通过配置定向页面那么我们如何来做呢我们就需要提供一个服务层完成定向比如说通过一个通用的类去完成这样的操作。123456789?xml version1.0encodingutf-8?configurationrouteurlsurl keykeyvaluevalue.aspx/url/urls/route/configuration具体的路由代码如下123456789101112131415publicclassRoute{publicRoute(){}/// summary/// 重定向服务/// /summarypublicvoidRedirectUrl(stringkey){stringurl XMLHelper.GetValue(key);}}当然我这里只是给个可能的思路去完成服务地址的跳转并不是比较好的方案。通过上面的讲解我们知道视图的更新并没有提出由谁来操作完成。通常来说有2中模式我们来看看吧后面我们会讲s解ASP.NET MVC模式中的视图更新的模式。我们接下来看看MVC在WEB端开发的变体吧那就是Model2模式我们先来看看这种模式相比之前的MVC模式都有哪些变化吧主要差别体现在以下几个方面在MVC模式中视图和模型有一定的关系模型发生变化将会通过观察者模式通知视图视图的更新我们是通过视图主动请求模型来完成更新的而在Model2中视图和模型是独立的视图的更新是通过控制器来完成的控制器根据模型的变化来通知视图的呈现及数据的变化还有就是该模式中用户的操作不是通过视图来捕获的是通过一个web组件前端控制器来完成的前端控制器负责拦截HTTP请求然后根据这个请求的URL和HTTP头信息去决定使用哪个控制器去处理该请求。基本上这个流程是Model2的处理流程。这个流程也是APS.NET MVC框架背后用到的模式相信大家对背后内容的理解将更容易让我们在使用框架的过程中加深理解。Model2模式相比MVC模式都有什么样的优点呢?可以肯定的是Model2具有更好的适应性更好的可测试性可维护性并且相比原始的MVC模式Model2的效率更高。这个怎么说呢原始的MVC模式流程我们的页面请求流程是这样的用户的每个操作将会产生一个HTTP请求然后服务器根据请求地址将映射一个处理页面然后该页面开始一个生命周期完成用户操作的请求。Model2模式的流程通过上面的图形我们知道用户的操作同样是通过HTTP请求被前端控制器捕获然后控制器将控制权交给具体的控制器去完成处理而不需要交给指定的页面去完成处理这样还需要给页面创建一个生命周期同时这种方式能够让视图做到非常的被动而不是主动更新我们将关注点转移到控制器中而不是视图上测试时更容易测试。我们需要注意的是Model2中的模型不是业务模型也不是领域模型这个模型是专门与视图进行交互的对象我们叫做ViewModelMVC框架中会为我们提供一个与ViewModel对应的容器。容器负责创建各类的ViewModel对象。MVC的流行也是因为它发挥了系统架构的原则分离功能点的重要性所以才会让它如此流行。但是MVC还不完美我们下面来看看改进MVC不足的另外一类模式MVP。4.3.2、MVP模式我们闲来看看MVP模式的解释MVP是将MVC模式中的控制器换成展示器,MVP模式巧妙的将模型从视图/控制器中分离开来我们将其叫做展示器我们需要知道MVP模式是从MVC模式的基础上衍生出来在MVP模式中我们通常是这样去完成交互展示器通过接口访问视图这样做的目的是展示器将不关心视图的实现形式只要实现接口那么就能通过展示器来完成相应服务。当然如果我们再考虑展示器与模型之前的调用如果也通过接口来完成那么我们就将关注的中心放在展示器上了这样更容易测试视图及模型都可以通过模拟来实现。这样将大大的提高可测试性。下面我们来看看MVC模式与MVP模式的差别我们还是通过看图说话的形式这样更直观。MVP模式MVC模式通过上面的图形我们应该比较清楚MVP模式相对MVC模式的改进了吧我这里就不多解释了。在MVP模式中我们更关注展示器和视图之间的交互我们使用该模式的一个主要目的就是通过展示器与视图之间通过接口调用的形式形成低耦合的形式我们更关注展示器然后不同技术实现的视图访问同一个访问器完成通用的服务。这样的方式有点类似SaaS的形式软件即是服务。我们来看看MVP模式的工作流程其实MVP模式并不是一个很容易实现的模式因为MVP模式需要为每个页面定义一个视图接口与展示器。当系统的页面有一定的规模时这将是非常大的工作量。因此我们需要根据项目的需要来决定采取的架构模式。我们下面来看看MVP模式衍生出来的一类新模式Presenter Model模式那么这个模式主要是应用在WPF中也会叫做Application Model 那么这个么模式与MVP有什么区别呢我们来看看总体来说区别不大PM更适合WPF和silverlight中构建表现层时采用的模式与MVP模式相同也是3个角色视图、展示器、模型。在MVP模式中我们通过为视图定义接口然后展示器通过接口调用的形式来和视图进行交互。而我们对视图的数据绑定则是通过视图实现接口来完成的。那么具体的实现技术可以有所不同。