旨在对Web应用发动革命的软件运动并不少，其中单页面应用（SPA）便是可信度很高的一种。此类应用有望进行更加模块化的开发，令应用更加容易地适配与多个设备，并拥有更好的应用生命周期管理—这些几乎是软件架构师希望的全部。

问题在于SPA开发的驱动要素中存在着相互竞争的愿景。这是一个新架构的愿景吗？抑或是特定应用的需求？架构师可通过以下手段驾驭这些不同的问题：

• 用循环的视角审视Web应用开发
• 框定一个一致的SPA图形用户界面（GUI）和模型
• 将SPA的原则带回服务器端
• 聚集于对合适的应用进行早期SPA开发

单页面应用诞生于拥有更多动态页面内容的Web 2.0革命。旧的超链接页面浏览模型给用户带来了不和谐的体验，而Web 2.0原则允许数据驱动时间在一个页面内创建，并让页面内容在需要的时候更新。这意味着应用似乎可以运行得更加流畅，乃至于到达可仿真桌面与本地资源接口的地步。

单页面应用的架构模型

可以认为，SPA演进的架构视角与应用视角的差异源自于这一事实，即某些公司将SPA模型视为改进应用稳定性和开发实践的一种手段，而其他的则聚焦在体验本身。因为一个由不一致目标驱动的技术演进本来永远就不应该存在，所以一开始从很高的层次开始在这两个愿景之间反复地考虑SPA就至关重要。

关于SPA行动背后的架构性框架的讨论有很多。简而言之，他们提出了这样一个Web应用结构，该结构协调了一种表示用户的应用视角及该视图与底层应用资源关系的对象模型。

这些模型的耦合会存放在另一个模型或数据结构中，有时候会用功能性要素来表示—如控制器，有时则用状态的产物表示，或者用户与SPA（通过Web 2.0型事件）及应用之间基于事件的交互。正是这一模型耦合的处理让单页面被当成了单应用。

SPA的架构模型专注于确保页面被当作传统软件中的组件来看。所有被使用的代码（尤其是脚本）都应该是本地的，且不会生成或导致每次两个页面组合来创建应用GUI时需要解决的全局命名空间，这是一个关键的需求。那么，所谓的组件化，就是SPA架构性愿景的驱动力，正如它通常对软件架构的推动一样。当然，除了用户体验的收获以外，组件化也可以有技术上的价值。

单页面应用的应用模型视图

SPA应用模型聚焦于通过减少应用执行时的页面转移来创建一种更好的用户体验。传统的Web 2.0应用通常仍能使用多页面，单页面仍然映射到若干应用组件上。大多数企业报告说他们对SPA的兴趣从渴望支持更多浏览器转向了多设备GUI。

SPA协调的起点是认识到SPA与脚本和网页编程有关，而不是与后端应用有关。SPA的主要目标是围绕着Web 2.0页面时间交互原则重构Web应用，以便体验可容易地转化到多个设备中，并对用户有效。这意味着首先要抱着支持这样一个逻辑活动为目标来设计用户交互，该活动应该涉及单页面与一套脚本，实现一次加载并执行直到活动完成。

一旦用户交互设计完成，下一步就是框定一个本地状态或事件模型，该模型应能描述页面处理与用户的交互及与任何后端应用交互。尽管这并非不可能，但是开发与服务器端功能多组件交互的SPA会更加困难。

这会产生一种要对应用服务器进行重构的诱因，其目的是为了以1:1的比例来支持SPA。就最大程度上而言，该模型应该让自己的变量及命名空间本地化，并通过应用的服务器端与其他SPA交互。这是为了减少对于用本地SPA控制器或模型来在多个SPA之间保留状态的需求。

如果充分应用的话，这套推荐将会使得包含少量SPA的高级别的用户与应用的交互支持高度的页面交互处理。SPA的数量以及SPA与服务器交互的本质然后就将决定后端处理应该如何进行优化来支持这一新的结构。

SPA在架构与应用之间进行协调问题的最后一点是找到合适的应用。有些应用本来就是多步骤的，每一个步骤都代表了一整页的信息并支持单个当前的后端事务。

看起来是逻辑分离的应用步骤不会因为组合到一起而获得任何好处，无论是用SPA还是任何其他技术。此类应用也不大可能从将页面以各种方式构建起来中获得任何好处。这些步骤是处理应用唯一的逻辑手段。记住，能够复合应用并将其转化为组件只有在应用在业务层面具备价值的情况下，且应该在技术层面进行支撑。

单页面应用已经被滥用了。许多脚本都太过复杂，难以被当作单页面加以正确处理和维护，而组件化的好处也会因为SPA太大而被稀释。以技术驱动力来平衡好应用与业务是为企业想出SPA优化模型的最好方式。