表示层设计模式：Front Cooller前端控制器应用与影响因素分析.pdfVIP

表示层设计模式:FrontController（前端控制器）

2009-01-07：

本页容

上下文

问题

影响因素

解决方案

示例

结果上下文

测试考虑事项

相关模式

上下文

您已经决定使用Model-View-Controller(MVC)模式将动态Web

考察了PageController

应用程序是基于可配置的规则来动态确定页面导航的。

返回页首

问题

如何为非常复杂的Web应用程序构建最佳的控制器结构，以便在避免代码重复的同时

返回页首

影响因素

下面是适用于FrontController模式的、由Model-View-Controller

•如果在系统的不同视图内公共逻辑，则需要集中此逻辑才能减少代码重复

体可性的关键。

•

图检索数据并重复数据库代码相比，在一个位置实现对此数据的检索是更

•如MVC中所述，测试用户界面代码往往是耗时而乏味的。通过区分单各自的角

仅适用于模型代码（在MVC中已说明），而且适用于控制器代码。

以下影响因素可能使您决定使用FrontController，而不是PageController。

•PageController的一般实现方法涉及为各个页面所共享的行为创建一个基类。

决定对于特定功能来说更具体，而不是所有页面共有的。

•为了避免在基类中添加过多的条件逻辑，您会创建更深的继承层次结构以删除

的应用程序中，只使用一个包含应用程序公共功能的基类可能是很有用的。每类

来问题。

•PageController解决方案描述了每个逻辑页面使用一个对象。当需要跨多个

此解决方案将不可行。例如，假定在Web应用程序中具有复杂的可配置导航

（应用程序必须根据其当前状态查找下一步要前进到哪个位置。

•由于PageController是通过每个逻辑页面使用一个对象来实现的，因此，很

致地应用特定操作。例如，安全性以协调方式实现。让每个视图或页面控制

因为它可以被不一致地应用，并导致安全问题。此问题的其他解决方案还将在

•对于Web应用程序来说，URL与特定控制器对象的关联可以是强制性的。例如

面用于收集信息。此向导包括许多必备页面和许多基于用户输入的可选页面。

必须使用基类中的条件逻辑来实现可选页面，才能选择下一页面。

返回页首

解决方案

FrontController通过让单个控制器负责传输所有请求，从而解决了在PageContro

本身通常分为以下两部分实现：处理程序和命令层次结构（见图1）。

图1:FrontController结构

处理程序具有以下两项职责：

•检索参数处理程序接收来自Web服务器的HTTPPost或Get请求，并从请

•选择命令处理程序首先使用请求中的参数选择正确令，然后将控制权转

图2显示这两项职责。

图2:FrontController的典型方案

命令本身也是控制器的一部分。命令代表具体的操作，这在Command模式

后，将由命令选择使用哪个视图来显示页面。

返回页首

示例

请参阅在ASP.NET中使用HTTPHandler实现FrontController。

返回页首

结果上下文

FrontController模式具有下列优缺点：

优点

•集化控FrontController用于协调向Web应用程序发出的所有请求。

而不是PageController

安全性和使用情况。

•线程安全。由于每个请求都涉及创建新令对象，因此命令对象本身不需要

避免了线程安全问题。但是，这并不意味着您可以完全避免线程问题，因为命

必须是线程安全的[Fowler03]。

•配只需要在Web服务器中配置一个前端控制器；处理程序执行其余的

一些Web服务器是很难配置的。使用动态命令可以添加新令，而无需进

缺点

•性能考虑事项FrontControl