Single Page Application - 下一代的Web应用程序 http://www.jscpx.cn/post/Single-Page-Application---%e4%b8%8b%e4%b8%80%e4%bb%a3%e7%9a%84Web%e5%ba%94%e7%94%a8%e7%a8%8b%e5%ba%8f.

aspx

顾平的博客 Javascript Client Page

致力于新一代Web应用程序开发环境框架设计

Single Page Application - 下一代的Web应用程序

下一代的 应用程序
十月 18, 2007 22:42 by andrew 搜索

输入搜索内容 搜索

在Web Service, Ajax, Web 2.0, REST等Web应用与技术话题热潮，带动许多第二代的Web开发技术成长之后，这些话题也渐渐地消退。不过许多人可能不曾发现，其实这些技术名词，是在慢慢地显露一点： Web应用程序逐渐从Server Side转移到Client Side，也就是浏览器身上。本篇文章要从以往的Server Side Web应用程序，其开发方式与演进来介绍Single
Page Application(SPA) 与现今所有主流Web技术。我在Web 2.0过去，现在与未来及介绍Ruby On Rails都有提到一些Web技术的演进，比较明显的趋势就是从静态到动态页面，而设计的方式也更程序化。而在http://atedev.wordpress.com/2007/01/09/web20：éŽåŽ»ï¼Œç¾åœ¨åŠæœªä¾†/ 也有读者在前言提到，技术并不是将一个名词安上去就好。我相当赞 日历

<< 一月 2008 >>

同这句话，因此也在这篇文章中希望来做个总整理，以技术及历史来看看Web是怎样成长的。1. Web应用程序的演进 1.1 动态网页 1.2 Rich Internet Application 2. Single Page Application 2.1 所依赖的Web技术 2.2 SPA的架构 2.3 Rails与SPA 3. 结论
30 31 1 2 3 4 5
日 一 二 三 四 五 六
Web应用程序的演进
应用程序的演进 6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
动态网页尽管Web并不是一个三言两语能拿个版本号码来解释，但实际上Web技术确实有些明显的分隔点。最早期我们熟知的就是静态网页，这应该没啥问题。尽管在2000前，php,asp就开始流行，坊间的书上也都称之为动态网页。而我在此提及的动态网页程序
动态网页程序，实际上却是从php4释出的那一年开始。这边要让大家了解的分界点，其实是php4开始被许多商
动态网页程序
业公司所采用，而软件的形式也更为套装化，而不再像之前大家认定的「动态」网页仅仅只是拿来完成一些简单的区块来与一般的静态网页整合。在2004年的时候，Web Framework的产生，创造了Web应用程序另一个新的高峰。而在这个时候也开始有一些Rich Web Client概念的雏形了。我将Ruby On Rails定为一个分界点是因为，他颠覆了传统动态网页还在 27 28 29 30 31 1 2
3 4 5 6 7 8 9
使用设计方式，而改用MVC。但要注意的是Ruby On Rails尽管整合了Ajax与进阶Javascript函式库，但还是没有改变回传完整或部分HTML的方式，意思便是HTML的产生始终在Server Side。Rich Internet Application 一直到现在，有相当多的Web应用程序，都还是维持使用URL来切换各种功能与画面。而这些以「页面」为主的程序，并不太需要控制
DOM，就不常遇到跨浏览器问题。然而自从Firefox逐渐也在市场占有一席之地，Javascript的应用普及之后，跨浏览器问题也接着发生。为了避开各种不同的浏览器所带来的问题，各大企业都独力发展自己可以嵌入在浏览器的应用程序。早期如 Java Applet及微软的的Active X，算是Rich Internet Application(RIA)的开始，但效能方面还是差强人意。直到2004年 相关文章

的时候，RIA出现了两种不同的实做方法：一种是承袭以往需要安装额外Runtime或是在特定浏览器才能执行的方式，称做Sandbox；另一种是只采用CSS,HTML，并以Javascript控制HTML DOM的Dynamic HTML方式，优点就是只需要浏览器就可以执行。而后者也延伸出利用Offline Database或是Ajax+Web Service来传送与储存程序数据，并可以储存成一个独 人工智能简介

意识心理学（3）
立页面的Web应用程序，称做Single Page Application(SPA)。SPA最典型的例子，就是Gmail。Google尽力克服了跨浏览器的问题，将Javascript发挥的淋漓尽致，让大家惊叹光靠纯粹的Web技术竟能做到如此程度。而我将2005定为Sandbox RIA真正开始的年代，也是因为Adobe并购Macromedia，而有了较完整的开发环境与资源，并不是以往单纯地嵌入 意识心理学（2）

Flash。这个契机也促使微软改变策略，比起效能较差的Asp.Net，而拿Sliverlight作为Web下一代主力军。RIA或SPA都是学习历程长，语言多又复杂的Web应用程序技术，也因此发展速度相当缓慢，但不可小看的是这些优点： ·
意识心理学（1）
相较以往在Server上产生HTML并回传至浏览器，任何画面皆利用浏览器本身或附加的功能来产生。形同于借用了Client Side
CPU的运算资源，减少Server成本。使用者感受到的互动性与响应速度皆有大幅的提升。 · 由于Server并不是每次都回传复杂庞大的HTML，而是利用XML或JSON传输数据的部分，使用的频宽也相对变小。 · Server Side除了使用传统XML Web Service，更可以采用REST，让Client的应用程序可以更快速掌握数据的新增修改删除(CRUD)并简化 归档

呼叫的服务URL。 · 2007
十月 (1)
能够快速Mashup其它的Web应用程序资源，又能拥有高速的执行效能。 下表列出了Web技术的演进，要注意到后三种技术集合，其时间是并行的：
静态网页 动态网页程序 Web应用程序
应用程序 Rich Internet Application with Sandbox Single Page Application 九月 (1)
时期 2000以前 2000(php4释出)~2004 2004(Ruby On Rails释出)以后 2005(macromedia被adobe并购)以后 2004(Gmail释出beta)以后
分类

总论 (1)
表现
CSS CSS,HTML,Javascript CSS,HTML,Javascript Flash, Sliverlight CSS,HTML(DOM)
© Copyright 2008
层

Sign in
逻辑
Javascript Template或自行撰写 Web Framework Action Script, C# Javascript或是撰写Web Service的语言
层

资料
HTML Database(SQL) Database(ORM) Database(ORM) Offline Database, Web Service
层
开发
网页编辑程序 整合HTML及Server Side语言的编辑器 整合Web Framework的IDE 整合Sandbox的IDE 整合Server Side与Client Side语言的IDE
方式
运算 所有数据直接透过Web Server送出，除了硬盘 因为使用了Server Side语言来Render表现层，运算多 运算资源平均被分散在Server及Client，但Client需要Sandbox去执行，所以会消耗
因为使用了Server Side语言来Render表现层，运算多半会消耗在Server 运算资源平均被分散在Server及Client
资源 读取，几乎不需要额外的运算 半会消耗在Server 更多CPU资源
数据
传送完整的HTML 传送完整的HTML 传送部分或完整的HTML 只需第一次传送HTML及内嵌程序(Flash或Sliverlight)，其余传送XML 只需第一次传送HTML及Javascript，其余可传送XML或JSON
格式

学习同一种Server Side语言，搭配简单的HTML,CSS,JS观念便能够有 整合Ajax或进阶Javascript函式库，REST及MVC。使得 使用者接口反应快速，变化多且美观。兼顾窗口程序的反应速度，且能部分兼容 完全兼容传统HTML应用，及任何可能的Web应用程序Mashup。可以采用不同的传输方式，并

优点 简单易学
成果 设计概念更为对象导向化 传统HTML应用。 和REST及浏览器快取来节省频宽，使得整体反应相当快速。
无法让使用者储存任何应用程序数据，任何数 对于庞大的应用程序，便得花上大量的Server成本。程序反应速度受限 设计方式更为简单快速，但相对于传统的动态网页程序 除了CSS,HTML,JS以外还需学习一两种不同的语言才能进行开发。RIA通常程序 除了CSS,HTML,JS以外还需学习一种撰写Web Service的语言。需要相当熟悉DOM及CSS，也
缺点
据必须藉由人工设计 于服务器负载，需要丛集架构来弥补。 付出更大的Server成本。 数据较大，在开始使用前必须等候一段下载时间。 需考虑浏览器的差异，开发起来相对地困难许多。
表现层的演进可以得知，不管是RIA利用sandbox或者是SPA利用DHTML作为表现层，相较起来传统以文字HTML拼凑出画面的作法已经无法符合使用者的需求。更动态，更弹性的作法才能让使用者获得操作感。而在逻辑层上，演进到了SPA则是变得较为复杂。如果是使用Web Service作为Server Side，除了必须撰写该语言外，也还是得撰写Javascript来控制画
面的呈现。而这也影响到开发方式，以往的编辑器多半着重一种主要的语言上，但现在的Web IDE多半都可以完整的处理所有浏览器的语言，及多种Server Side语言。例如Aptana IDE就是最好的例子。数据层的演进就比较简单，直到RIA的时期，还是相当依赖传统的Database。但SPA的时期，就可以采用Offline Database，这里指的就是Google Gears。但如果
要使用传统的Online Database，全部都尚未有Javascript的Client，就必须透过Web Service来转换数据。而在SQL到ORM的演进上，虽然使用对象导向的作法减缓执行速度，但相对降低开发难度，带来更大的价值。
Single Page Application
技术Ajax为Asynchorous Javascript And XML，早期Ajax被用作来传输单纯的HTML或是XML，并且利用DOM的innerHTML属性来更新部分HTML内容。如今Ajax在SPA中被当作重要的传输媒介(Transport)，无论模板数据到应用程序数据，都是利用Ajax在背景传输完后，再由Javascript Template来产生HTML。JSON为Javascript Simple
所依赖的Web技术
所依赖的
Object Notation，在标准的Javascript语法中，以{ }及[ ]这两个语法，可以宣告对象与数组，并可以使用eval函式将他转换为Javascript对象。例如object=eval(”({a:’b'})”)，此时object对象便有一个属性”a”其值为”b”。在SPA中，JSON被运用来作为一种数据格式，藉此取代复杂的XML，以节省频宽。而传输的JSON数据又可以快速还原为javascrip对象，又更节省程
序执行的时间。在SPA中，HTML DOM是一个最重要的元素，尤其是DIV及SPAN等Container的操作更是。由于绝大多数的画面都不进行任何换页的动作，程序里大部分都是在控制DOM及Container。而对于A (Anchor)而言，href里的URL也没有太大意义，多半都是在onclick里写javascript，或是用Javascript函式库去bind onclick事件。由于直接呼叫浏览器提供
的DOM函式库功能，会遇到像IE一样不符合W3C规格的问题。要选用一个合适的Javascript扩充函式库，如Prototype.js或是jQuery，如此才不会有太多跨浏览器问题。CSS在以往的Web应用程序中，多半都拿来当作画面的修饰，布景主题或是颜色特校。但在SPA中，必须要熟悉CSS的Dimentation(长宽控制)，Classification(显示行为)，Positioning(定位)。
在无法换页的状况下， 只能靠着移动，隐藏，显示这些方法来控制画面的元素。如果要了解这些进阶CSS的主题，都可以在w3school里的教学找到。Trimpath是Google为了SPA而开发出来的一个函式库集合，也可以说是Rails的Javascript版。如果要撰写上述第一种SPA，就必须利用到Trimpath的全部，而第二种只需要用到Trimpath Javascript Template即
可。Javascript Template(JST)如同PHP的Smarty一样，是标准的模板技术，只是采用的语言是Javascript。为了撰写SPA，必须要好好地运用JST。快取的机制在SPA也相当的重要，为了达到让使用者感受到程序的反应快速，就必须应用多方面的快取。 · View Cache：SPA中的View就是指已经显示出来的HTML，很多常用，而不需要经常改变的HTML，
就可以将放在Container(DIV或SPAN)里。不用的时候就隐藏，需要的时候就显示。而另一种方式是可以用z-index将选单或是清单的Container放在最下层，而要回到这个清单的时候就将盖在其上的container隐藏。 · Template Cache：一般来说JST的模板数据只要读取一次就可以，又因为这些只是字符串，可以直接就存在Hash里。 · Javascript
Cache：在我提出的SPA实做中，有一个特性是将各个JST的「行为」程序代码分开，就如同sap.net将aspx与cs档分开的作法一样。而如果采用这个作法，不需要重复读取的javascript就必须要快取。 · Data Cache：资料快取是最难的一部份，牵扯到了快取一致性的问题。而现在在javascript中并没有对于XML或JSON的数据快取解决方案，未来如果能够
有这样的函式库，就能够更提升整体的效率。 以上说明的都是Client Side所必须要使用到的技术，而Server Side的技术多半与Service Design息息相关。REST为Representational State Transfer，他比较像是一种设计样式(Design Pattern)，而不是Web技术。在以往Web应用程序的规划中，URL并不完全具有意义，传输的内容型态多半是HTML，而HTTP的各
种动作也并 未完全利用。在SPA中，由于需要在不同时间传输各种数据，如HTML模板，JS模板，或是XML及JSON数据。此时REST的设计技巧就可以节省下很 多重复的命名，而让程序代码整体更有意义。支持REST设计样式的Web Framework如Ruby On Rails，让整体设计较为简单。SPA的架构
的架构SPA就分类而言，算是RIA的一种，只是不采用任何的
sandbox而已。典型的SPA是不需要任何的后端的Web Service或是Offline Database，只需要一个htm档或是一个网页就能够运作，如微软的HyperText Application(HTA)就是，但还是缺乏完善的数据储存能力。第一种SPA程序，如同著名的Google Reader离线版，具有一个离线数据库与一个同步管理程序，在有网络联机的时候，会将数据同步回在线的数据库。
这个最大的优点就是完全利用了Client的CPU资源，使用者虽然看见的是网页，但却是在使用在本机执行的独立应用程序，因此速度是相当流畅。比起一般的动态网页，这样子的使用体验更能够颠覆一般人对于「网页」的看法，而逐渐了解何谓 Web应用程序。另一个例子是使用Trimpath函式库撰写成的NextAction，是一个多功能的ToDo List。另一种就是较简单
的SPA，不具有离线浏览的能力，但是承袭了使用javascript的高效能。必须提及的是Server Side并不是采用XML，而是可以快速转换为Javascript对象的JSON，来当作Web Service。如此Server Side的语言只需要具备能够快速将对象serialize成JSON的能力即可。Rails与
与SPA这个小节所要说明的是相当技术性的部分，无法说明的太详细，有兴趣的读者可以写
mail一起讨论。为了简化观念，我使用Sequence Diagram来说明Rails要如何应用在SPA上：· URLRequester是一个javascript函式，主要的工作就是以REST方式对一个URL进行不同Content-Type的Request，并且将回传的资料产生HTML，并填到container里显示出来。 · HTTPRequest在这里作为进行Ajax呼叫的传输媒介。 ·
RailsController表示服务器端对应至特定URL的程序，在这里也必须使用REST方式来响应。也因此如果要求content-type为HTML的时候就传JST模板，要求JSON的时候就传数据，要求javascript的时候就传javascript文件。 · RailsModel代表服务器端的数据库，在要求数据的时候，势必定要连数据库来取得数据的。而回传的时候，就将ruby对象serialize成
JSON。 1. Client呼叫URLRequester函式，例如http://servername/controller/action/id。 2. HTTPRequest送出一个要求，并指定Content-Type为HTML。 3. RailsController接到指定的URL，并执行controller#action。我将JST写在rhtml里面，JST基本上也是html，不过是模板的卷标换成{}而已。因为REST设计方式会因为指定的content-type回
传对应的型态，此时直接将内容的JST文件传回。 4. 在前面我有提及快取的重要性，所以这里就快取住这个JST，下次要求同样的内容就可以直接使用而不用重复传输。 5. 对于同一个URL，使用HTTPRequest送出要求，并指定Content-Type为JSON。 6. 因为REST的特性，这次会执行到content-type为JSON时的程序代码，接着就可以照
一般方式使用Rails Model读取数据库。 7. Model传回的Ruby对象，当然就要转换成JSON回传。而在ruby中相当简单地便是呼叫to_json就可以转换了。 8. 回传的JSON，并和刚刚快取的JST，使用trimpath javascript template函式库产生成HTML，并更新至container里。 9. 在这里我采用行为javascript程序代码与范本分离的方式，所以还是
以HTTPRequest再次传送要求，并将Content-Type指定为Javascript。 10. 同样地根据要求的content-type，会回传javascript文件。 11. 快取，并呼叫eval执行回传的javascript。 12. 将container显示在想要放置的画面区域。
结论
许多人都在说Web 2.0可能又是另一次的泡沫化，这个热潮怎样开始的，又怎样消退的，也是相当明显。网络上对于各种新技术名词的炒作，将不同应用层次的技术，全部搅和在一起说明或 称做是最终解决方案，也模糊了使用者的眼睛。那么，在这个时代，到底还有什么可以相信，可以学习的？唯一能够做的就是重新审视这些技术，了解因果。就可以知道哪些
作法是适合用在自己现在的项目，那些是本质相同的，哪些是跨大其词的。根本的观念正确，就不需要担心这些延伸的技术是否会有误解或误用。

目前没有人评价该文章

类别:
操作: 永久链接 | 评论 (0) | Comment RSS

第1页 共2页 1/20/2008 12:34 PM

Single Page Application - 下一代的Web应用程序 http://www.jscpx.cn/post/Single-Page-Application---%e4%b8%8b%e4%b8%80%e4%bb%a3%e7%9a%84Web%e5%ba%94%e7%94%a8%e7%a8%8b%e5%ba%8f.aspx

添加评论
名称*
电子邮件* (将显示你的 Gravatar 肖像)
网站
评论*

保存评论

Live preview

一月 20. 2008 12:28

欢迎您提出宝贵意见！

第2页 共2页 1/20/2008 12:34 PM