页面控制器与前端控制器可以混合使用，不必强求一致

页面控制器为Web站点上每个逻辑页面（更准确说是每个”动作”，比如一次点击）各配一个输入控制器，承担三项基本职责：解码URL并提取后续处理所需的数据；创建并调用模型对象来处理这些数据（确保模型完全不需要知道HTML请求长什么样）；决定用哪个视图来显示结果、并把模型相关信息传给它。实现上可以用脚本（脚本本身兼任处理程序和控制器）或服务器页面（结合模板视图放进同一文件，但一旦请求里的数据提取或视图选择涉及复杂逻辑，服务器页面就容易被麻烦的scriptlet代码拖累，解法是引入辅助对象专门处理这部分逻辑）。作者观察到一个值得警惕的团队行为：有些团队坚持”一刀切”——要么所有URL都用服务器页面处理，要么全都用脚本处理，图的是方法统一带来的一致性；但作者认为这种一致性带来的好处，常常被两种代价抵消掉——简单URL被脚本化后变成大量只起传递作用、毫无信息量的样板代码，复杂URL被塞进服务器页面后又充斥着难以维护的scriptlet。更务实的做法是按每个URL控制器逻辑的实际复杂度分别选择：逻辑少或没有逻辑的用服务器页面（简单直接、易改），逻辑复杂的用脚本（结构清晰）；即便放大到”页面控制器 vs 前端控制器”这个更高层次的选择，同一个站点里一部分请求走页面控制器、另一部分走前端控制器也完全可行，两种模式混用并不困难，尤其是团队还在持续重构演进的情况下。可迁移启发：为了图省事而对所有情况套用同一种技术方案，看似降低了决策成本，实则可能让每一种场景都各自承受本不必要的额外复杂度——按具体场景的实际复杂度分别选择合适的工具，即使因此要维护两套模式，总代价往往比强行统一更低。