传统Web框架 PK AJAX -来自BJUG邮件列表的讨论

所谓的web request和web remoting这种区别对于服务器实际上是不存在的，服务器接收到的是一样的HTTP请求。我觉得这样划分可能更好：是否需要在服务器组装完整的HTML。
新型的Ajax应用，尤其是以前曾经讨论过的one page的应用中，这种需求是完全不需要的。服务器只需要第一次将一个HTML模板和由一堆JS组成的客户端应用发给客户端就可以了。随后服务器只需要给客户端提供数据就可以了。

其实自己建造基础架构也是一件很愉快的事情，尽管如此，我仍然可以告诉大家，80%的情况下都不需要。对于这些通用性的问题，正在成长的Ajax框架，都会解决掉。
另外，即使基于JSON-RPC、Buffalo这些框架可以非常方便地做RPC，我仍然建议要谨慎对待RPC方式开发所带来的幻觉。基于消息请求/相应（就是以数据为中心的应用）的调用方式耦合度会更小，应该是JS远程调用的首选。这样的架构甚至可以在将来支持智能手机一类的客户端。

新型的Ajax应用，尤其是以前曾经讨论过的one page的应用中，这种需求是完全不需要的。服务器只需要第一次将一个HTML模板和由一堆JS组成的客户端应用发给客户端就可以了。随后服务器只需要给客户端提供数据就可以了。

其实自己建造基础架构也是一件很愉快的事情，尽管如此，我仍然可以告诉大家，80%的情况下都不需要。对于这些通用性的问题，正在成长的Ajax框架，都会解决掉。

即使基于JSON-RPC、Buffalo这些框架可以非常方便地做RPC，我仍然建议要谨慎对待RPC方式开发所带来的幻觉。基于消息请求/相应（就是以数据为中心的应用）的调用方式耦合度会更小

我之所以说one page应用仅仅适用于中小型应用完全是因为js语言的限制以及浏览器能力的限制。在buffalo的演示中，页面切换过程中对于全局变量的管理完全没有办法，每次swtichView的时候变量会重新创建或者覆盖。如果页面多，浏览器很可能死掉——这个已经在一个完全使用buffalo做进销存的系统中得到了验证。那个系统大约有10余个子系统，每个子系统包含约20项功能。我在体验的过程中感觉相当差。所以one
page应用只适合小型或者中小型web应用。我相信，在dlee所描述的自己的应用中，也应该是标准的页面切换方式而不是buffalo采用的那种方式才能使用大型应用的要求。

dlee与robbin所争论的焦点并不在此，而是应用领域的问题。我将现有的web应用分为两种：企业管理类应用(MIS)与消费类应用（WEB2.0，
may be）。这又回归到了Friendly URL的问题。不得不提的是， ajax很难实现友好url,
但这个偏偏是内容型应用或者社会化类型应用的基础要求；然而另一方面，对于MIS系统而言，更看重组件与server端的交互，而不是url与server的交互。应用的不同，两者的架构有很大区别。对于MIS系统，按照dlee的想法或者ajax/buffalo的推荐方式，应该如下：

Domain object > Service > html page

调用方式：通过json-rpc或者buffalo直接调用service层的方法，与html进行交互。这种系统的特点是用户交互性强；

而内容型系统展现的内容较多，往往传递给叶面需要展示的结构并不复杂：

domain object > service > MVC > view

这样做的好处是，在很多情况下，MVC都很灵活，可以控制展现内容的展现方式：使用什么技术来展现，使用什么url来展现。这对于消费类应用，这很重要。

然而两者并非不可融合，存在交互的地方。没有纯粹的操作型应用，在MIS系统中，也可能存在需要进行友好url的地方；在内容型应用中，对于发表留言、删除留言等这种操作，显然不需要友好url,
ajax就有了用武之地。

关于url的相关考虑，以下blog使我的一些考虑，供参考：

http://michael.nona.name/archives/132

rpc的方式，本质上就是一个proxy模式。就是在本地实现一个远程对象的stub，通过这个stub调用远程对象上的方法。我需要重新实现一个proxy吗？网上的代码随处可见，大家都可以想明白。

我来举一个例子（又是没有代码！）：
XML-RPC和Web Service，xml-rpc是一种RPC方式的调用，而基于SOAP的Web Service是一种基于消息请求/响应的调用模式。Web Service比XML-RPC耦合度更低，RPC的方式容易被某些开发者滥用，误以为调用远程方法没有成本，因此轻易发送大量的调用请求。所以我建议多采用类似于Web Service一类的方式来发送请求，就是认为传输的是静态的数据，而不是对象。同时还可以把多个数据的请求和响应打包在一起发送，更加有效地利用带宽。

我确实没有写代码，但是如果你有时间的话，建议你去看看Ajax in Action，里面对于这种方式有很好的代码。另外基于XMLHttpRequest的remoting方案并不像你说的只有3种。实际上几乎任何一种Ajax框架都有自己的remoting实现，包括你非常熟悉的Prototype。

robbin我觉得你有点太在意设计在美学上的价值了。实际上Ajax诞生的使命就是彻底改善Web开发的交互性，remoting方案在这里只是一个配角，主角还是强大成熟的widget库。
在我看来dojo或者prototype自身的remoting方案完全可以满足大多数要求了。

对于robbin上面说到的情况，大部分情况下我会采用最直接的方式来处理，一些问题我相信都可以找到现成的workaround。而且我并不认为这种解决方式在架构层面上有什么了不得的问题。

Michael Chen说到：
所以one page应用只适合小型或者中小型web应用。我相信，在dlee所描述的自己的应用中，也应该是标准的页面切换方式而不是buffalo采用的那种方式才能使用大型应用的要求。

回答：
说实话我并不是很赞同one page的应用，我们以前的架构也有页面的完全切换，并不是one page的应用，不过切换是在前台由JS来控制的。相当于在前台实现了Controller的功能。

另外服务器端Web层的MVC，在新型Ajax应用中，即使有价值也是有限的。价值就是将Ajax应用交付到客户端。在Ajax应用中，原先的粗粒度的MVC无法满足要求，因此需要在原先服务器划分的MVC的View中划分出新的MVC来。就是说在Ajax开发中，MVC架构会以不同的粒度嵌套起来，服务器端只定义最大粒度，即整个页面粒度的MVC。更小的粒度由客户端的JS来定义。这些内容在Ajax in Action的第4长有详细论述，上次BEA的活动中我也有所介绍。

而在以数据为中心的应用中，实际上这个服务器端定义的大型MVC的价值也是可疑的。是否仍然需要这些灵活性值得怀疑。如果确定不需要这种灵活性，可以完全抛弃服务器端的MVC架构，改为一种基于服务的架构，在客户端代码中实现MVC。这种开发方式我们已经应用了3、4年，并没有发现非常严重的问题。

关于做数据请求的粒度问题，如果粒度太细，可能会引起性能的问题，所以Ajax in Action的作者提出了一种类似于EJB2.x时代的VO的解决方案，现在应该叫做DTO了，并且把多个请求打包在一起。这种方案虽然从美学上看不是很好，但是却是一种实用的解决方案。

在服务器端生成html片断与生成数据片断, 然后在浏览器端组装在增强用户体验这一方面是完全一致的, 没有什么区别.