| | | | | | | [文章信息] | | | 作者: | 微软架构与模式小组 | | 时间: | 2004-04-26 | | 出处: | MSDN开发精选 | | 责任编辑: | 方舟 | |
| [文章导读] | | | 本文描述了MVC模式的架构、设计及其ASP.NET实现，同时介绍了Web表示模式集群的另外两个模式：筛选器和页面缓存模式 | |
| |
|
| | | |
|
|
|
|
|
中等复杂程度的优化—Page Controller(页面控制器)
使用Page Controller模式接受来自页面请求的输入、调用请求对模型执行的操作以及确定应用于结果页面的正确视图。分隔调度逻辑和所有视图相关代码。如果合适，创建用于所有页面控制器的公用基类，以避免代码重复并提高一致性和可测试性。图5显示了页面控制器与模型和视图的关系。
图6、使用BaseController消除代码重复
页面控制器可接收页面请求、提取所有相关数据、调用对模型的所有更新以及向视图转发请求。而视图又将根据该模型检索要显示的数据。定义独立页面控制器将分隔模型与Web请求细节（例如会话管理，或使用查询字符串或隐藏表单域向页面传递参数）。按照这种基本形式，为Web应用程序中的每个链接创建控制器。控制器因而将变得非常简单，因为每次仅须考虑一个操作。
为每个网页（或操作）创建独立控制器可能会导致大量代码重复。因此应该创建BaseController类以合并验证参数（请参阅图6）等公用函数。每个独立页面控制器都可以从BaseController继承此公用功能。除了从公用基类继承之外，还可以定义一组帮助器类，控制器可以调用这些类来执行公用功能。
大多数情况下，页面控制器取决于基于HTTP的Web请求的具体细节。因此，页面控制器代码通常包含对HTTP头、查询字符串、表单域、多部分表单请求等的引用。因此在Web应用程序框架之外测试控制器代码非常困难。唯一方法是通过模拟HTTP请求和分析结果来测试控制器。这种类型的测试既费时且易出错。因此，要提高可测试性，可以将依赖Web的代码和不依赖Web的代码分别放入两个单独类中（请参阅图7），这是Page Controller的变体实现。
图7、分隔依赖Web的代码和不依赖Web的代码
Page Controller是大多数动态Web应用程序的默认实现方式，它简单，Web应用框架内置，可扩展性及其开发人员责任的分隔等等优点使其在Web开发得到广泛的应用，不过每页面一控制器、较深的继承树和对于Web框架的依赖等等也是其比较明显的限制。
高度复杂的优化
—Front Controller(前端控制器)
Front Controller通过让单个控制器负责传输所有请求，从而解决了在Page Controller中存在的分散化问题。控制器本身通常分为以下两部分实现：处理程序和命令层次结构（见图8）。
图8、Front Controller结构
处理程序具有以下两项职责：
1) 检索参数。处理程序接收来自Web服务器的HTTP Post或Get请求，并从请求中检索相关参数。
2) 选择命令。处理程序首先使用请求中的参数选择正确的命令，然后将控制权转移给该命令以便执行处理。
图9、Front Controller的典型方案
在前端控制器中，所有请求都通过单个（通常是两部件）控制器来传送。控制器的第一个部件是处理程序，第二个部件是Commands（命令）[Gof95]的层次。命令本身是控制器的一部分，代表控制器触发的特定操作。在执行该操作之后，命令选择要使用哪个视图来呈现页面。通常，构建的此控制器框架使用配置文件将请求映射到操作，因此，它在构建之后便于更改。当然，其缺点在于这种设计固有的复杂程度。
|
|
|
|
|
|
|
|
