在更加复杂的应用系统中，如何考虑尽可能避免导航代码的重复，甚至考虑基于可配置的规则来动态确定页面导航，那么Page Controller和Front Controller某种意义来说是对于MVC模式在更加复杂的系统的优化。
中等复杂程度的优化—Page Controller(页面控制器)
图6、使用BaseController消除代码重复
页面控制器可接收页面请求、提取所有相关数据、调用对模型的所有更新以及向视图转发请求。而视图又将根据该模型检索要显示的数据。定义独立页面控制器将分隔模型与Web请求细节（例如会话管理，或使用查询字符串或隐藏表单域向页面传递参数）。按照这种基本形式，为Web应用程序中的每个链接创建控制器。控制器因而将变得非常简单，因为每次仅须考虑一个操作。
为每个网页（或操作）创建独立控制器可能会导致大量代码重复。因此应该创建BaseController类以合并验证参数（请参阅图7）等公用函数。每个独立页面控制器都可以从BaseController继承此公用功能。除了从公用基类继承之外，还可以定义一组帮助器类，控制器可以调用这些类来执行公用功能。
图8、Front Controller结构
处理程序具有以下两项职责：
1) 检索参数。处理程序接收来自Web服务器的HTTP Post或Get请求，并从请求中检索相关参数。
2) 选择命令。处理程序首先使用请求中的参数选择正确的命令，然后将控制权转移给该命令以便执行处理。
在前端控制器中，所有请求都通过单个（通常是两部件）控制器来传送。控制器的第一个部件是处理程序，第二个部件是Commands（命令）[Gof95]的层次。命令本身是控制器的一部分，代表控制器触发的特定操作。在执行该操作之后，命令选择要使用哪个视图来呈现页面。通常，构建的此控制器框架使用配置文件将请求映射到操作，因此，它在构建之后便于更改。当然，其缺点在于这种设计固有的复杂程度。
遗漏之后的补充
到目前为止，已经完整地展示了Web表示模式中MVC的实现架构，同时在此技术上对于中等复杂和高度复杂的情况提出了Page Controller和Front Controller作为优化的手段，在构建Web表示的应用程序，已经给出了相对完整的解决方案，细心的读者是否发现，是不是还少了一点什么？在构建Web应用程序的时候，除了构建一个“良构”的系统（这表现在MVC的分离和系统的可扩展），我们还需要考虑应用程序的安全和性能，因此我们选取了Interceptiing Filter和Page Cache作为Web表示模式的补充内容。
Intercepting Filter(筛选器)
如何围绕Web页面请求来实现公共的预处理和后处理步骤？这是筛选器需要解决的问题，使用此模式，您创建一串可组合的筛选器，以便在Web页面请求期间实现公共的预处理和后处理任务。
图10、一串可组合筛选器
筛选器构成了一系列独立模块，在将页面请求传递到控制器对象之前，这些模块可以链接在一起以执行一组公共的处理步骤。因为各个筛选器实现的是完全相同的接口，所以它们彼此之间没有显式依赖性。因此，可以在不会影响现有筛选器的情况下添加新的筛选器。您甚至可以在部署时添加筛选器，方法是基于配置文件动态地对它们进行实例化。
对各个筛选器的设计应该尽可能让它们不对是否存在其他筛选器作出任何假设。这样可以维护可组合性，即添加、删除或重新排列筛选器的能力。此外，某些实现Intercepting Filter模式的框架不会保证筛选器的执行顺序。如果发现多个筛选器之间存在很强的相互依赖性，最好采取调用帮助器类的常规方法，因为这样可以保证保留筛选器序列中的约束信息。Intercepting Filter的直接实现方式是一个筛选器链，这个筛选器链可以用来遍历一个由所有筛选器组成的列表。Web请求处理程序在将控制权传递到应用程序逻辑之前将首先执行筛选器链。
图11、Intercepting Filter类关系图
当Web服务器收到页面请求时，请求处理程序首先将控制权传递给FilterChain（筛选器链）对象。此对象维护着一个包含所有筛选器的列表，并按顺序调用每个筛选器。FilterChain可以从配置文件中读取筛选器顺序，以实现部署时的可组合性。每个筛选器都有机会修改传入请求。例如，它可以修改URL，或添加应用程序要使用的头字段。执行完所有筛选器之后，"请求处理程序"将控制权传递给控制器，后者将执行应用程序功能（见图12）。
图12、Intercepting Filter序列关系图
因为在处理Web请求时通常需要有截取筛选器，所以大多数Web框架都为应用程序开发人员提供了将截取筛选器挂靠到请求-响应过程中的机制。
Page Cache(页面缓存)
如果动态生成的Web页被频繁请求并且构建时需要耗用大量的系统资源，那么，如何才能改进这类网页的响应时间？页面缓存通过对从动态网页生成的内容进行缓存来提高请求响应的吞吐量。默认情况下，在ASP.NET中支持页面缓存，但除非定义有效的过期策略，否则，不会对来自任何给定响应的输出进行缓存。要定义过期策略，可以使用低级OutputCache API或高级@OutputCache指令。
页面缓存的基本结构是相对简单的。Web服务器维护包含预先生成的页面的本地数据存储（见图13）。
图13、页面缓存的基本配置
下面的序列图阐明了页面缓存可以改进性能的原因。第一个序列图（见图2）描述尚未缓存所需页面的初始状态（即所谓的缓存未命中）。在这种情况下，Web服务器必须访问数据库，并生成HTML页，再将其存储在缓存中，然后将它返回给客户端浏览器。请注意，此过程比不进行缓存的情况稍慢，因为它执行了下列额外步骤：
1. 确定页面是否已缓存
2. 将页面转换为HTML代码，然后存储在缓存中
与数据库访问和HTML生成相比，其中的任一步骤都不应该花费很长时间。但是，因为在此情况下需要进行额外处理，所以您必须确保在系统完成与缓存未命中关联的步骤之后连续多次命中缓存（如图14所示）。
图14、缓存未命中的序列（当页面不在缓存中时）
在图15所示的缓存命中情况下，页面已经处于缓存中。通过跳过数据库访问、页面生成和页面存储，缓存命中节省了循环。
图15、缓存命中的序列（页面处于缓存中时）
在ASP.NET中可以采用下述三种模式来实现缓存策略：
1．将这样的指令插入到要缓存的每个页面中。指令指定刷新间隔（以秒为单位）。刷新间隔不依赖于外部事件，而且缓存不能全部刷新。
2．Vary-By-Parameter Caching.此模式使用Absolute Expiration的变型，该变型使开发人员能够指定影响页面内容的参数。因此，缓存将存储页面的多个版本，并按参数值为这些页面版本编制索引。
3．Sliding Expiration Caching.此模式与Absolute Expiration（绝对过期）的类似之处是，页面在指定的时间内是有效的。但是，在每次请求时都会重置刷新间隔。例如，您可能使用滑动过期缓存，将一个页面缓存最长10分钟。只要对页面的请求是在10分钟内发出的，就将过期时间再延长10分钟。
