代码非常困难。唯一方法是通过模拟HTTP请求和分析结果来测试控制器。这种类型的测试既费时且易出错。因此，要提高可测试性，可以将依赖Web的代码和不依赖Web的代码分别放入两个单独类中（请参阅图7），这是Page Controller的变体实现。
Page Controller是大多数动态Web应用程序的默认实现方式，它简单，Web应用框架内置，可扩展性及其开发人员责任的分隔等等优点使其在Web开发得到广泛的应用，不过每页面一控制器、较深的继承树和对于Web框架的依赖等等也是其比较明显的限制。
高度复杂的优化
—Front Controller(前端控制器)
Front Controller通过让单个控制器负责传输所有请求，从而解决了在Page Controller中存在的分散化问题。控制器本身通常分为以下两部分实现：处理程序和命令层次结构（见图8）。
处理程序具有以下两项职责：
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页面请求期间实现公共的预处理和后处理任务。
筛选器构成了一系列独立模块，在将页面请求传递到控制器对象之前，这些模块可以链接在一起以执行一组公共的处理步骤。因为各个筛选器实现的是完全相同的接口，所以它们彼此之间没有显式依赖性。因此，可以在不会影响现有筛选器的情况下添加新的筛选器。您甚至可以在部署时添加筛选器，方法是基于配置文件动态地对它们进行实例化。
对各个筛选器的设计应该尽可能让它们不对是否存在其他筛选器作出任何假设。这样可以维护可组合性，即添加、删除或重新排列筛选器的能力。此外，某些实现Intercepting Filter模式的框架不会保证筛选器的执行顺序。如果发现多个筛选器之间存在很强的相互依赖性，最好采取调用帮助器类的常规方法，因为这样可以保证保留筛选器序列中的约束信息。Intercepting Filter的直接实现方式是一个筛选器链，这个筛选器链可以用来遍历一个由所有筛选器组成的列表。Web请求处理程序在将控制权传递到应用程序逻辑之前将首先执行筛选器链。
当Web服务器收到页面请求时，请求处理程序首先将控制权传递给FilterChain（筛选器链）对象。此对象维护着一个包含所有筛选器的列表，并按顺序调用每个筛选器。FilterChain可以从配置文件中读取筛选器顺序，以实现部署时的可组合性。每个筛选器都有机会修改传入请求。例如，它可以修改URL，或添加应用程序要使用的头字段。执行完所有筛选器之后，"请求处理程序"将控制权传递给控制器，后者将执行应用程序功能（见图12）。
因为在处理Web请求时通常需要有截取筛选器，所以大多数Web框架都为应用程序开发人员提供了将截取筛选器挂靠到请求-响应过程中的机制。
Page Cache(页面缓存)]
如果动态生成的Web页被频繁请求并且构建时需要耗用大量的系统资源，那么，如何才能改进这类网页的响应时间？页面缓存通过对从动态网页生成的内容进行缓存来提高请求响应的吞吐量。默认情况下，在ASP.NET中支持页面缓存，但除非定义有效的过期策略，否则，不会对来自任何给定响应的输出进行缓存。要定义过期策略，可以使用低级OutputCache API或高级@OutputCache指令。
页面缓存的基本结构是相对简单的。Web服务器维护包含预先生成的页面的本地数据存储（见图13）。
下面的序列图阐明了页面缓存可以改进性能的原因。第一个序列图（见图2）描述尚未缓存所需页面的初始状态（即所谓的缓存未命中）。在这种情况下，Web服务器必须访问数据库，并生成HTML页，再将其存储在缓存中，然后将它返回给客户端浏览器。请注意，此过程比不进行缓存的情况稍慢，因为它执行了下列额外步骤：
1. 确定页面是否已缓存
2. 将页面转换为HTML代码，然后存储在缓存中
与数据库访问和HTML生成相比，其中的任一步骤都不应该花费很长时间。但是，因为在此情况下需要进行额外处理，所以您必须确保在系统完成与缓存未命中关联的步骤之后连续多次命中缓存（如图14所示）。
在图15所示的缓存命中情况下，页面已经处于缓存中。通过跳过数据库访问、页面生成和页面存储，缓存命中节省了循环。
在ASP.NET中可以采用下述三种模式来实现缓存策略：
1．将<%@ OutputCache Duration="60" VaryByParam="none" %>这样的指令插入到要缓存的每个页面中。指令指定刷新间隔（以秒为单位）。刷新间隔不依赖于外部事件，而且缓存不能全部刷新。
2．Vary-By-Parameter Caching.此模式使用Absolute Expiration的变型，该变型使开发人员能够指定影响页面内容的参数。因此，缓存将存储页面的多个版本，并按参数值为这些页面版本编制索引。
3．Sliding Expiration Caching.此模式与Absolute Expiration（绝对过期）的类似之处是，页面在指定的时间内是有效的。但是，在每次请求时都会重置刷新间隔。例如，您可能使用滑动过期缓存，将一个页面缓存最长10分钟。只要对页面的请求是在10分钟内发出的，就将过期时间再延长10分钟。
结束语
自此，我们已经完整地介绍了Web表示集群中相关的各个模式，关于在MVC模式中Observer(观察者)模式的用法，我们会用专门的篇幅来介绍，文
Page Controller是大多数动态Web应用程序的默认实现方式，它简单，Web应用框架内置，可扩展性及其开发人员责任的分隔等等优点使其在Web开发得到广泛的应用，不过每页面一控制器、较深的继承树和对于Web框架的依赖等等也是其比较明显的限制。
高度复杂的优化
—Front Controller(前端控制器)
Front Controller通过让单个控制器负责传输所有请求，从而解决了在Page Controller中存在的分散化问题。控制器本身通常分为以下两部分实现：处理程序和命令层次结构（见图8）。
处理程序具有以下两项职责：
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页面请求期间实现公共的预处理和后处理任务。
筛选器构成了一系列独立模块，在将页面请求传递到控制器对象之前，这些模块可以链接在一起以执行一组公共的处理步骤。因为各个筛选器实现的是完全相同的接口，所以它们彼此之间没有显式依赖性。因此，可以在不会影响现有筛选器的情况下添加新的筛选器。您甚至可以在部署时添加筛选器，方法是基于配置文件动态地对它们进行实例化。
对各个筛选器的设计应该尽可能让它们不对是否存在其他筛选器作出任何假设。这样可以维护可组合性，即添加、删除或重新排列筛选器的能力。此外，某些实现Intercepting Filter模式的框架不会保证筛选器的执行顺序。如果发现多个筛选器之间存在很强的相互依赖性，最好采取调用帮助器类的常规方法，因为这样可以保证保留筛选器序列中的约束信息。Intercepting Filter的直接实现方式是一个筛选器链，这个筛选器链可以用来遍历一个由所有筛选器组成的列表。Web请求处理程序在将控制权传递到应用程序逻辑之前将首先执行筛选器链。
当Web服务器收到页面请求时，请求处理程序首先将控制权传递给FilterChain（筛选器链）对象。此对象维护着一个包含所有筛选器的列表，并按顺序调用每个筛选器。FilterChain可以从配置文件中读取筛选器顺序，以实现部署时的可组合性。每个筛选器都有机会修改传入请求。例如，它可以修改URL，或添加应用程序要使用的头字段。执行完所有筛选器之后，"请求处理程序"将控制权传递给控制器，后者将执行应用程序功能（见图12）。
因为在处理Web请求时通常需要有截取筛选器，所以大多数Web框架都为应用程序开发人员提供了将截取筛选器挂靠到请求-响应过程中的机制。
Page Cache(页面缓存)]
如果动态生成的Web页被频繁请求并且构建时需要耗用大量的系统资源，那么，如何才能改进这类网页的响应时间？页面缓存通过对从动态网页生成的内容进行缓存来提高请求响应的吞吐量。默认情况下，在ASP.NET中支持页面缓存，但除非定义有效的过期策略，否则，不会对来自任何给定响应的输出进行缓存。要定义过期策略，可以使用低级OutputCache API或高级@OutputCache指令。
页面缓存的基本结构是相对简单的。Web服务器维护包含预先生成的页面的本地数据存储（见图13）。
下面的序列图阐明了页面缓存可以改进性能的原因。第一个序列图（见图2）描述尚未缓存所需页面的初始状态（即所谓的缓存未命中）。在这种情况下，Web服务器必须访问数据库，并生成HTML页，再将其存储在缓存中，然后将它返回给客户端浏览器。请注意，此过程比不进行缓存的情况稍慢，因为它执行了下列额外步骤：
1. 确定页面是否已缓存
2. 将页面转换为HTML代码，然后存储在缓存中
与数据库访问和HTML生成相比，其中的任一步骤都不应该花费很长时间。但是，因为在此情况下需要进行额外处理，所以您必须确保在系统完成与缓存未命中关联的步骤之后连续多次命中缓存（如图14所示）。
在图15所示的缓存命中情况下，页面已经处于缓存中。通过跳过数据库访问、页面生成和页面存储，缓存命中节省了循环。
在ASP.NET中可以采用下述三种模式来实现缓存策略：
1．将<%@ OutputCache Duration="60" VaryByParam="none" %>这样的指令插入到要缓存的每个页面中。指令指定刷新间隔（以秒为单位）。刷新间隔不依赖于外部事件，而且缓存不能全部刷新。
2．Vary-By-Parameter Caching.此模式使用Absolute Expiration的变型，该变型使开发人员能够指定影响页面内容的参数。因此，缓存将存储页面的多个版本，并按参数值为这些页面版本编制索引。
3．Sliding Expiration Caching.此模式与Absolute Expiration（绝对过期）的类似之处是，页面在指定的时间内是有效的。但是，在每次请求时都会重置刷新间隔。例如，您可能使用滑动过期缓存，将一个页面缓存最长10分钟。只要对页面的请求是在10分钟内发出的，就将过期时间再延长10分钟。
结束语
自此，我们已经完整地介绍了Web表示集群中相关的各个模式，关于在MVC模式中Observer(观察者)模式的用法，我们会用专门的篇幅来介绍，文
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
