MVC至SWMVC演化案例揭示场景约束决定合规性

书中用MVC架构演化到SWMVC（Spring Web MVC）架构的真实案例，验证了同一次架构演化在不同应用场景下会产生完全不同的合规结果——这是本章最有说服力的一个结论。SWMVC相比MVC新增了frontctl层专门与用户交互、把view层独立出来处理模型视图映射、并隔断model与view的直接联系（model必须经controller和frontctl才能把新模型传给view），整个演化过程被拆解成OP1到OP13共13个原子演化操作依次验证。在场景1（静态化网站，视图只在首次加载生成、之后不主动更新，只有用户请求更新数据时才刷新）中，最终SWMVC架构满足正确性、安全性、活性、公平性全部四类约束，演化被判定为合规。在场景2（数据频繁更新、view需要主动推送新视图模型的网站）中，同样的最终SWMVC架构却违反了活性和公平性约束——因为两个场景对”backview消息何时产生”“view是否会被忽略”这类行为提出的LTL约束完全不同：场景1要求backview不一定产生（活性约束以”非”的方式描述），场景2则要求backview必须产生。这个对比揭示了一个容易被忽视的道理：架构演化”对不对”从来不是一个脱离场景的绝对判断，同一份架构改动，换一个应用场景（也就是换一套约束条件），结论可能截然相反。书中进一步指出，架构演化过程包含很多个中间阶段，每个阶段都可能影响架构的属性约束，仅仅观察最终演化结果并不能反映演化过程中出现过的问题——这些问题可能在后续阶段被掩盖，但依然会成为架构设计正确性或其他时态属性的隐患（例如案例中演化AF阶段因复合片段loop缺少循环条件而引入死循环，虽然后续FTC/FCC阶段修复了这个问题，但如果不逐阶段验证、只看最终结果，这类曾经存在过的隐患就会被完全忽略）。这正是本章反复强调”要从正向演化关系逐阶段分析评估”，而不能只验证演化前后两个端点的根本原因。