Front Controller（前端控制器）
http://msdn.microsoft.com/zh-cn/library/ms978723.aspx
上下文
您已经决定使用Model-View-Controller (MVC) 模式将动态 Web 应用程序的用户界面逻辑与业务逻辑分隔开来。您已经考察了Page Controller模式，但您的页面控制器类具有复杂的逻辑，并且是较深的继承层次结构的一部分，或者，您的应用程序是基于可配置的规则来动态确定页面导航的。
问题
如何为非常复杂的 Web 应用程序构建最佳的控制器结构，以便在避免代码重复的同时实现重用性和灵活性？
影响因素
下面是适用于 Front Controller 模式的、由 Model-View-Controller 带来的各种具体的影响因素：
-
如果在系统的不同视图内复制公共逻辑，则需要集中此逻辑才能减少代码重复量。删除重复的代码是改进系统的总体可维护性的关键。
-
数据检索最好也集中在一个位置进行处理。一个好的示例是，让一系列视图使用数据库中的相同数据。与让每个视图检索数据并重复数据库访问代码相比，在一个位置实现对此数据的检索是更好的做法。
-
如 MVC 中所述，测试用户界面代码往往是耗时而乏味的。通过区分单各自的角色，可以提高总体可测试性。这不仅适用于模型代码（在 MVC 中已说明），而且适用于控制器代码。
以下影响因素可能使您决定使用 Front Controller，而不是 Page Controller。
-
Page Controller 的一般实现方法涉及为各个页面所共享的行为创建一个基类。但是，随着时间的推移，由于要增加非所有页面公用的代码，这些基类就会不断增大。若需要定期重构 此基类以确保其只包括公共行为，则需要制定规则。例如，您不希望由页面检查请求并决定（基于请求参数）是否将控制权转移给另一个页面，因为这种类型的决定 对于特定功能来说更具体，而不是所有页面共有的。
-
为了避免在基类中添加过多的条件逻辑，您会创建更深的继承层 次结构以删除条件逻辑。例如，在具有三个功能区域的应用程序中，只使用一个包含应用程序公共功能的基类可能是很有用的。每个功能区域可能还有另一个类，该 类继承总体应用程序的基类。乍一看，这种类型的结构是简单的，但它通常会导致非常脆弱的设计和实现，并给代码带来问题。
-
Page Controller 解决方案描述了每个逻辑页面使用一个对象。当需要跨多个页面对处理过程进行控制或协调时，此解决方案将不可行。例如，假定在 Web 应用程序中具有复杂的可配置导航（以 XML 格式存储）。当收到请求时，应用程序必须根据其当前状态查找下一步要前进到哪个位置。
-
由于Page Controller 是通过每个逻辑页面使用一个对象来实现的，因此，很难在 Web 应用程序的所有页面中一致地应用特定操作。例如，安全性最好以协调方式实现。让每个视图或页面控制器对象分别处理安全性是有问题的，因为它可以被不一致地应用，并导致安全问题。此问题的其他解决方案还将在Intercepting Filter 中进行讨论。
-
对于 Web 应用程序来说，URL 与特定控制器对象的关联可以是强制性的。例如，假定您的站点具有类似向导的界面用于收集信息。此向导包括许多必备页面和许多基于用户输入的可选页面。在使用 Page Controller 实现时，必须使用基类中的条件逻辑来实现可选页面，才能选择下一页面。
