标签：
PageController(页面控制器)
上下文
决定使用MVC来动态创建应用程序时，需要关注把用户界面、控制器和业务逻辑分开。
问题：
如何创建比较复杂的应用程序的控制器？
影响因数：
MVC主要关注业务模型与视图的分开，不太关注控制器。对于胖客户而言，控制器与视图分开的需求不是很明显。但在瘦客户端，控制器与视图本身就是分开的。由于视图是在客户端的浏览上显示，而控制器是在服务器端执行。
由于不同用户的操作，会产生多个操作，共用一个视图。如果控制器和视图不分离，视图代码会重复出现。例如产品查询系统，产品查询、分页会使用同一个视图，但执行不同的操作。
Web系统中不同的控制器和视图在加载时会经理身份验证、授权、字符串查询等一系列操作，这些操作会使代码重复。
脚本服务其端页面容易创建，但显示逻辑和业务逻辑混在一块，随着复杂程度的增加，难于维护、扩展和重用。
从测试角度看，测试视图比较困难，但测试业务逻辑比较容易且重用度高，因此如果把视图与业务逻辑、控制器分开，将容易进行测试。
解决方案
使用PageController接收用户输入，并根据输入调用业务逻辑的操作，并返回结果，最后确定使用哪个视图。这一模式使业务逻辑与视图逻辑进行分离（如下图）。通常的做法是，把公用的业务逻辑写成一个基类，PageController继承这个基类，做到易于测试和一致性。
页面控制器接收用户的输入并提取输入的数据，同时调用模型操作，把模型操作的结果在视图上呈现。视图根据模型检索的数据进行显示。页面控制器把模型与视图进行分离，页面控制器承担了Http请求的任务，如会话管理、缓存、认证等任务。因此我们可以为每个链接创建一个控制器，每个控制器执行一个操作，这将变的简单。
为每个页面创建一个控制器，将导致大量代码的重复，因此需要把这些公共的操作封装到一个基类控制器中，每个页面控制器都继承该基类，也可以使用一些帮助类。
如果页面相似度越高，越复杂，继承度越深。如产品查询系统有些需要显示产品列表有些需要输入数据，我们会制作两个基类一个是ListController和DataEntryController，页面控制继承他们。这样随着系统的复杂度增高，变的不容易维护，因此开发人员人为PageController是不好的设计，而FrontController是好的设计，其实这是由于对PageController缺乏完善的支持。
大多数框架都支持PageController，如ASP、JSP、PHP等。这些框架大多数把控制器和View在服务器进行了混合，很难把进行分离。而ASP.NET对该模式进行了分离，把控制器放到一个独立类中，使用了代码隐藏技术。
变体
大多数情况下，页面控制器依赖于Http请求，如请求域、请求头部、表单域、字符串查询等信息，因此可以把与Http请求有关的操作封装到一个类中，把与Http有关的逻辑和与Http无关的逻辑进行了分离，见下图：
这样做的缺点是，增加系统开销，好处是，容易维护和开发，尤其是多人开发的团队尤为重要。
PageController的优点：
1、 简单，每个链接或请求，对应一个控制器，容易创建和维护，理解起来也容易。
2、 内置框架，所有框架都默认实现了该模式。
3、 容易扩展，可以使用一些帮助类进行扩展。
4、 职责分离
5、 重用度高
PageController的缺点：
1、每个页面一个控制器。由于简单，只能在导航比较简单的Web系统中使用该模式，如果系统比较复杂建议使用Front Controller.
2、继承深度比较大：由于该模式采用继承的方式实现重用，如果业务比较复杂，继承深度比较大，不易维护。
3、依赖Web框架
在 ASP.NET 中实现 Page Controller
在Asp.NET中构建Web应用程序，利用内置的PageController框架，同时利用ASP.NET的事件驱动特性
实现策略
在默认情况下Asp.net页面框架实现了PageController的各种概念。Asp.NET 页面框架自动实现了，在客户端感知用户操作，把用户请求发送到服务器端，服务器端自动调用合适的方法进行响应。这个过程对开发人员来说是不可知的。页面框架可以进行扩展，页面框架的各种事件都是对外开放的。
页面生命周期
注意：还有几个页面处理阶段没有在这里列出。不过，这些阶段不用于大多数页面处理情况。
实现方式
使用Micrisoft.net设计方案 第三章Web表示模式 Web模式集群详细介绍
标签：
原文地址：http://www.cnblogs.com/ljf10223063/p/4543962.html
