两步视图的模块数量优势，与设计自由度的限制

两步视图把”领域数据转HTML”拆成两个阶段：第一阶段把模型数据组装成一个不含任何HTML细节的”逻辑屏幕”结构（字段、标题、表格等面向表现但不涉及具体样式的元素）；第二阶段把这个逻辑屏幕结构渲染成真正的HTML。这个拆分带来的核心价值在多外观场景下最为直观：如果用单阶视图（模板视图或转换视图），每个”屏幕×外观”的组合都要各自配一个视图模块——10个屏幕配3种外观就要维护30个单阶视图模块；换成两步视图后，只需要10个第一阶段模块（每屏幕一个）加3个第二阶段模块（每种外观一个），总数从”屏幕数×外观数”降到”屏幕数+外观数”，屏幕和外观越多，这个节省就越可观；即便只有单一外观，两步视图依然让”全局改版”这件事变得轻松——只需要改动共享的第二阶段，不用满世界找每个页面各自的样式代码。但这份收益完全建立在一个前提上：能不能把站点里所有页面的表现需求，收敛进同一个足够简单的”面向表现结构”里——如果站点很复杂、每个页面的外观差异巨大，很难在不同屏幕间找到足够多的共性来提炼出这样一个通用结构，两步视图这时反而成为累赘；换句话说，这个面向表现的结构本身会反过来约束整个站点的设计自由度，对许多站点而言这种限制相当明显。此外，两步视图还需要程序设计人员亲自编写渲染器和控制器对象，不像模板视图那样能让非程序员用可视化工具直接设计页面，任何设计上的调整都绕不开程序员的参与。

结构图：

flowchart LR
  A["10屏幕×3外观"] --> B["单阶视图<br/>需要 10×3=30 个模块"]
  A --> C["两步视图<br/>需要 10+3=13 个模块<br/>(10个第一阶段+3个第二阶段)"]
  D["前提:能否把所有屏幕收敛进<br/>同一个足够简单的面向表现结构"] -.->|"不满足则收益不成立"| C