文章：有理化表现层

web 应用的特色瘦客户端模式不完善，弊端越来越多，很多年来沿袭的一些习惯性设计模式也逐渐成为分布式应用发展中的障碍。而一些陈旧的折衷解决方案也随 着开发环境的转变而不合时宜。Ganesh Prasad 和 Peter Svensson 合作撰文就这一现象作了简要的分析，详细解释了为什么以及如何将表现层技术迁移到它本该遵循的开展方向上来。

他们追溯到直接导致陈旧的根深蒂固的表现层开发陋习的直接历史原因：

……（1）作为无处不在的客户端“应用平台”成就了浏览器的绝对重要性，应用因此很容易部署；（2）各商家间的分裂剥夺了平台原本拥有的发展潜能。……

……一方面，越来越多的应用需要采用 Web 方式向用户发布；另一方面，发布应用必须的平台却是如此不可靠。这时候，企业该怎么办？……

……最常见的决策是仅依赖浏览器那些非常有限的基本功能——显示格式简单的 web 页面、链接、提交表单等，而表现层的逻辑则转移到服务供应商能够控制的系统部分——Web 服务器。……

他们认为在旧式开发策略指导下的表现层开发现在完全应该由 SOA 构架来替代：

……一个“老”原则的重新兴起，或者说是“面向服务构架（SOA）”的流行，间接推动了表现层外观的改变。正如其所定义，SOA 更合理地组织业务逻辑，而且为实现整个逻辑提供统一接口。建立好构架的基础是囊括整个应用各个方面的各个互不相关的离散层，用户接口（UI）借助 SOA 能 够实现真正的表现层构架。这样的表现层没有业务逻辑，只有业务服务的客户。……

在文中，Prasad 和 Peter Svensson 解析了新模式实现的框架中包含的各个元素，解释了客户端的处理方式。同时，他们也一针见血地指出了这一新模式的基础原则：

……该模型的核心主题是分解表现层和业务逻辑等几方面的顾虑。……

最后，他们简要列出了新模式背后所蕴含的意义。

• 精简的构架模型包含了表现层和业务逻辑层无阻抗失配的完美集成。
• “web 服务器”的角色（首次）更为合理。
• 支持 MVC 这个表现层最自然的设计模式。
• 保证应用间端对端数据的完整；统一了“瘦客户”和“富客户”模型。
• 支持无论是基于 SOAP 还是 REST 的服务。
• 服务器运行更加轻便，因为其不需再负累表现层相关逻辑。
• 降低了同组业务服务的多用户接口创建的开销。
• 复用表现层模块的压力骤降，如果业务层设计合理的话，从表现层调用正确的服务就能实现足够的复用。

详细内容，请阅读全文：有理化表现层。