65.9K
CodeProject 正在变化。 阅读更多。
Home

Ajaxion - 独立 AJAX - 第 1 部分(共 2 部分)- REST 的 UI 视角

starIconstarIconstarIconstarIcon
emptyStarIcon
starIcon

4.91/5 (21投票s)

2008 年 7 月 8 日

CPOL

5分钟阅读

viewsIcon

40781

一篇关于如何构建未来 Web 应用程序的文章,该应用程序依赖于当前标准,而较少依赖技术。

引言

本文从 UI 视角探讨了 REST。本文的 第 2 部分(即将更新)将提供 C# 和 Java 示例,解释什么是独立 AJAX:REST 的 UI 视角。

背景

不久前,我读了一篇关于可能的技术趋势的文章,例如使 AJAX 独立化——不再需要 ASP、JSP 或 PHP 等。那时我还不知道 REST,也不知道 REST 如何能够清理所有沉重的服务器技术。

在我的项目中实现支持 AJAX 的“服务器页面”有时并不方便。为什么还要关心例如 viewstate,而不直接摒弃它呢?你只需要 HTML、CSS 和 JavaScript 作为能够消耗服务的客户端。

我认为我们所熟知的 MVC 已经或多或少过时了。仅仅为了适应不同设备而“只”替换视图,这只是一个理论上听起来不错的笑话。“构建 Web 应用程序”现在越来越意味着“集成客户端应用程序以消费服务”。过去我们听说过 SOA,但我们需要设备市场的爆发才能真正推动行业朝着真正健壮的标准发展,而不是仅仅销售技术——本质上只是“同一种东西的新版本”,并配有昂贵的工具来为你处理复杂性。你尝试实现 SOA,然后 MVC 分享 SOA 部分的模型,最终会得到一个紧耦合的设计模式结构(带有不同名称的复杂性),或者如果你敢于解耦,它可能会变得更加复杂。

独立 AJAX - REST 的 UI 视角

假设我们需要构建一个 Web 应用程序,基于一些初步的讨论,这些讨论最终未能提供清晰的功能概览(一如既往),因此你可以先构建一个不完整的框架。

  • 我们处于第一个冲刺阶段……一些敏捷团队可能已经在交付“可用的软件”方面遇到了困难……嗯,其中的一部分……然后以极大的敏捷性进行更改……并且在不断变化的需求压力下——大多数时候客户需要为自己的流程建立更好的结构,然后定制软件才会有意义……越早获得更好的需求,成本就越低。大多数客户希望在真正参与之前看到一些东西。如果能尽快提供一个可用的网站,让客户随意尝试并获得感觉、理解差距……而静态 HTML 本身将用于完成开发,那就太好了。

  • 在客户端……现在通过已经“运行”的静态 HTML 原型澄清了大部分功能,是时候进行更多的冲刺了。是时候在实时 HTML 上进一步推进 Web 设计了——你不再需要因为 ASP、JSP 或 PHP 而打扰 Web 设计师,因为他们通常“喜欢”HTML、CSS 和 PhotoShop,而且你也不用让开发人员疯狂地重现一些 Web 设计师的“疯狂想法”……在 HTML 上看起来不错,但在“X”服务器页面脚本中却很可怕。只需优化 Web 设计,当“某个服务器端”可用时,添加 AJAX 调用层,负责这些工作的人甚至不需要在同一个房间……并非说良好的沟通不好,我只是想强调事物可以多么解耦。
  • 服务器端……一旦你了解了数据库可以是什么样子以及你需要什么样的业务逻辑(即使在第一个冲刺阶段与快速增长的静态 HTML 表示并行),就开始构建一个服务器端调用框架,其中方法返回甚至测试硬编码的数据,如果采用 TDD,还可以进行单元测试。目标是尽快提供服务器端以支持第一次 AJAX 调用……从已经外观不错的网站……然后再次前往客户那里……他会对他的软件增长速度如此之快以满足他的需求而感到兴奋……并将注意力集中在澄清你所需的一切。
  • 现在基本上清楚该做什么了,只需测试和完善应用程序,例如,交换尽可能短的 JSON 消息。
  • 如果客户突然发现他们的访问量将是预期的 1000 倍……只需将服务器端部署在更大的机器、应用服务器或更好的操作系统上。

关注点

  • 避免需求文档的开销,允许在实时组件上澄清功能:所见即所得,也是“抓住”客户的好方法。
  • 华丽的网页设计不再是初学者开发者的难题。
  • 专注于以 RESTful 的方式编写松耦合的数据服务。为什么浪费服务器资源去渲染“动态静态 HTML”而你大多可以避免它?如果你真的想,你的表示可以是 HTML,但 ROA 服务器端最重要的是一个优雅的 API,可以被任何客户端消费,而不仅仅是你的“网站”。
  • 保持 AJAX 和 JavaScript 层简单。同时注意不要让应用程序服务器因 AJAX 调用而臃肿……
  • 尝试在服务器端(即 API)中引入 TDD,客户端会在截止日期前发现新的“愿望”……还有什么比这更能让你信赖你的代码呢?
  • XML 在减少数据库复杂性或需要应用 XSL 时非常有用,但不要过度使用 XML,JSON 可能会更好。标准是好的,但你可能不需要 SOAP,一个简单的 HTTP servlet 本身就是一个服务。不沉迷于技术……这可以大大降低成本。

希望这有所帮助。

历史

  • 2008 年 7 月 8 日:初始帖子。
  • 2009 年 9 月 20 日:文章更新。
© . All rights reserved.