权衡单页面应用方法在部分或所有BPM应用中的适用性时需要考虑以下一些因素。

之所以叫做单页面应用是因为它们通过浏览器赋予用户对业务应用的完全访问，不需要加载新的页面。这样做对于用户来说结果是更快、响应性体验更好，对底层基础设施的利用也将更加高效。

其“秘密武器”是格式化信息和应用处理逻辑的页面在首次点击前就已经下载了，然后由浏览器运行脚本去执行任务。这需要调用Web服务来获取数据，否则的话就得与后端进行交互，但是不再需要更进一步的与页面展示相关的数据获取了。相反，只有受影响的页面元素需要更新，其整体效果是采用“真实”桌面客户端而非浏览器。

这一技术好处是有的，因为将浏览器与那么多的“智能”打包在一起意味着服务器的负载降低，网络流量减少。（理论上）这还意味着应用可在任何支持Web的设备上运行，相应地也可以进行管理或者开发。

实现预期好处需要进行平衡工作

你可能会想，听起来不错。那么，有什么条件呢？只有这个：视应用情况不同，可能需要花费可观的精力去让浏览器变得合适，然后还需要相当长的时间才能完成初始的下载。必须在开发单页面应用所需的工作量与采用它可能得到的好处之间进行小心的平衡—尤其是像业务流程管理（BPM）这样复杂的场景。

也许单页面应用（SPA）最简单的形式包括那些以一个长页面呈现的网站，上面还有一些链接，一旦点击则会导致某些不太复杂的功能在页面内发生（如打开一个通信录表格），而不是带你去到一个新的页面。此处脚本以相对直接的形式被触发出来，被放到了浏览器上的命令能够做的事情完全是在浏览器能力范围之内的。

另一方面，像BPM这样的应用则要复杂得多，处理放在核心的业务规则和引导逻辑的计算能力也要多得多。因此，怀疑把所有需要的功能都塞进浏览器中是否值得是合理的。

SPA还是BPM？看情况

其答案跟平常一样，基本上归结为“看情况”：要看用户预期，看你的技术基础设施，要取决于你植入的技能组合等等。以下是权衡针对全部或部分BPM应用采用SPA方案适用性时需要考虑的若干要素。

用例的性质。如果流程的步骤定义清晰且捆绑紧密的话用SPA最有意义。案例管理就是一个很好的例子，因为工作流步骤往往是清晰且可预测的。这一提供给浏览器的“指令集”可以预先定义好并且进行有效处理，这么做没有过载风险，而这种风险最终会抵消SPA本来具备的部分好处。

一致界面的需要。尤其是当大家一直使用同一工具有很长时间的时候，维护熟悉的界面外观对于简化升级或替换应用的过渡阶段来说就显得至关重要。采用SPA让你可以在很大程度保持前端界面与之前一样，哪怕后端的东西发生了改变。这一点在极大的舒适源自于“以一直以来习惯的方式做事”的流程充裕型的应用中特别重要。

浏览器支持JavaScript。SPA严重依赖于JavaScrip，所以对于那些对恶意软件及安全很敏感，要限制浏览器独立行动能力的的组织来说不是他们的选择。此外，许多浏览器，尤其是旧一点的浏览器也许并不能扛起这一重担。所以开发根本就不能在那种环境下运行的SPA几乎没什么意义。

带宽。不必持续加载页面信息意味着更少信息需要在服务器与客户端之间移动，而反过来又意味着支撑应用的带宽需求变低。这一点在发电厂建筑工地这类的地方可能会特别有用，因为这些地方基本上一开始几乎都是脱离电网的，但是又有很多流程需要执行和汇报。另一方面，会话开始是由于有那么多的页面和逻辑信息需要下载，在低带宽或带宽不稳的情况下加载该SPA可能会变得慢得不可接受。

离线的需要。在客户端运行所有逻辑意味着与服务器断开连接也没什么大不了。如果你支撑的用户需要在飞机或野外消耗时间的话，那么SPA可能就有意义了，因为哪怕在没有连接的情况下本地处理仍能继续。此外，记住Word of Pie首席分析师Laurence Hart的话：“你不能一直假定浏览器会正确退出，在客户端处理可以减轻这一点。”

云价格。如果你用了云提供商，并且事务要收费的话，那么服务器调用越少意味着成本越低—像BPM这样的重度处理的应用尤其如此。

必要技能。SPA开发要沉浸在脚本和网页编程上面，一般还要利用像Backbone、Angular, Ember以及React这样的SPA框架来完成。不是每一个组织都有员工熟悉这些框架，所以必须做出培训投资或者从外面带人进来完成工作这样的安排。

单页面应用未必适合所有情况

正如你所看见的一样，单页面应用可以是在采用浏览器上Web时赋予用户桌面式体验的一个相当有效的手段。与此同时，SPA也可以给后端带来一定的效能，甚至哪怕这并非SPA的主要初衷。

然而，SPA的构造意味着它们未必适合所有情况，在正确匹配工作需要与预期好处上面必须多加小心——尤其是在做BPM的时候，其影响程度足以令单页面展示不切实际。