XMLHTTP和浏览器端表现技术的讨论

说明一下，没有映射和转换。HTML需要数据，通过JS到servlet中取；Servlet需要数据，通过DTO从数据库中取，就是这样。传递的都是数据和指令，没有对象需要转换，也不存在序列化什么的。

我的经验和 jasonhsu 比较相似，jasonhsu 说的情况我都同意。很高兴 jasonhsu 在这种开发方式中找到了乐趣。

因为采用 XMLHTTP 做开发 B/S 之间交换的都是 XML 格式的数据，采用这种方式做开发，我们可以事先把需要显示的数据用 XML 写好，保存在后台的很多文件中，然后在后台写一个 Servlet，根据前台不同的请求返回不同的 XML 数据。采用这种开发方式，我们可以在完全没有数据库参与的情况下迅速做出所有的界面原型。也就是说我们可以只开发出表示层（页面+表示逻辑），然后再开发后台的代码，最后对接起来。其实一般的应用表示层开发的工作量在全部开发工作中所占的比例还是很重的，表示层都做完了，至少等于开发工作完成了一半。这种开发方式我们尝试过，证明是可行的，但是还需要进一步的完善。

至于 B/S 两端对象的序列化和同步，我觉得是没有必要的，这是 Java 程序员的思考方式。其实只要定义好一个 XML 的 DTD，开发出一套通用的框架就可以把 XML 的复杂性完全屏蔽起来了。B/S 之间交换的是 XML 格式的数据而不是对象及其属性。不过其他的表示层开发人员懂一些 XML 还是非常有必要的，连 XML 和 XPath 都不懂的表示层开发人员能算是合格的吗？我对此非常怀疑。

dlee写道：


我的开发方式与这还是有点不同，我不会将xmlDom保存成文件，它是消息，只在内存中瞬间存在。一个XMLHTTP过程结束后就不存在了，下一个过程开始时再去构造它。一个典型的构件VIEW层的实现只有三个文件需要保存，一个HTML，一个JS，一个Servlet，下面就是Hibernate的领地了。

我们也是这样的，不过我们后台用自己的框架。我上面说的是以一种以廉价的方式快速实现一个界面原型（实际上不能算原型了，因为这些代码其实将来都可以直接用的）的可能性。这种界面原型的开发采用 XMLHTTP 或者 Flex 的方式要比采用 Struts 更简单。

我们在2000年的时候，曾经大量运用JavaScript进行开发，那时候还是用PHP比较多一些。那个时候我也曾经一度沉迷于用层的效果做出来很炫的操作方式，很多操作为了实现的比较好，往往是服务器端和客户端结合起来实现，有时候需要用PHP动态填充Javascript的数组数据，然后Javascript在客户端再读取数据渲染，有时候也用到PHP来生成Javascript，然后Javascript在document.write的方式生成页面。

不过就我的经验来说，我宁愿用更多的scriptlet，也不愿意用JavaScript。两方面原因：

1、服务器端脚本嵌入页面，不管怎么说页面还算有点可视化的效果，在DW里面，但是如果用到Javascipt来动态产生页面就毫无动态效果了。

2、Javascript开发复杂的应用，调试和维护都是非常困难的事情，当一个页面的Javascipt对象比较多的时候，总会出现一些你意想不到的问题，例如有时候页面还没有完全load完毕，你就开始操作页面，此时由于上下文关系，有些include的Javascript定义到的DHTML对象还没有被load完毕，你一操作就报Javascript错误。很多这种错误是非常隐蔽和难以避免的。

因此，我现在宁愿多写几个页面，多几个页面间的状态控制，也不愿意写那些复杂的Javascript，增加潜在的难以控制的因素。

目前从大的厂商来说，MS走的是WebForms的路，这种方式其实也是尽量避免复杂的客户端编程，而多增加服务器端状态控制的思路；BEA/Oracle走的是Applet的路子，这也不用多说了；在Javascript方面比较强的实际上是Macromedia公司，看看DW里面那些内置的Javascript函数就知道Macromedia公司的功力，然而即便是macromedia公司自己也很少去用Javascript，他们宁愿运用大量运用flash。

总之， XMLHTTP在客户端的交互需要完全通过Javascript'来驱动，然而这种富Javascript技术的页面表现层解决方案我不认为它会成为主流。

PHP 这种开发方式即使动态生成 JS，仍然是一种试图依赖服务器端技术解决表示层问题的开发方式，这样的开发方式应该归为 Struts/Webwork/Tapestry 一类，与 XMLHTTP/Flex 这种客户端驱动的开发方式还是有相当大的差别的。

我们用 M$ Visual Interdev 调试 JS，感觉还不错，挺方便的。至于 robbin 说的其它情况确实存在，但是可能是久病成医吧，这些情况在我们看来都不是非常复杂的问题。可以把页面中的按钮 display 属性设置为 none，设置一个 onload 函数，在页面全部加载完的时候把页面中的按钮显示出来。

JS 有一个比较讨厌的特点是某个包含进来的 JS 文件中如果某个函数有错误，这个文件中所有的函数都不会被解析。这个时候查找到底错误出在何处就有些麻烦（需要到处加 alert 语句来查，确实非常原始）。不过其实也不是非常麻烦，只要记住最近在 JS 文件中修改了些什么就可以了，出错肯定是发生在那些地方。象 potian 这样精通 TDD 的高手使用 JS 做开发，可以使用 JsUnit 来以 TDD 方式做开发，我个人也是同意其实采用 TDD 的方式来保证代码质量是比依赖调试器更好的方式。

以XMLHTTP做为核心技术，Web应用的架构和传统C/S应用架构基本相同，将B/S方式下的服务器分发推送页面方式，改为在客户端请求调用页面方式，服务器端的功能变成很纯粹，就是提供类似于Web Services服务的业务接口供客户端调用。（这种方式我认为也是微软的一种商业思路，即充分利用桌面优势，将Web应用一步步拉向桌面，并通过Web Services进行企业应用集成。）

如果我们仔细分析的话，可以设计出很多基于XMLHTTP或者说基于“C/S”模式的Web应用框架，比如我们曾经采用XMLHTTP+XML+XSL+JS做过Web应用开发，MVC在这种方式下已经变成VC-CM模式（记得以前和dlee探讨过，当时dlee觉得我在客户端划分Controller过细了），而客户端对于页面组件的处理方式又有变化，是完全采用组件化编程还是全部提交给Server端处理，会有不同的框架设计方式。

如果采用这种框架模式，客户端的开发已经不是以前单纯的页面制作和简单的JS代码编写，已经是实实在在的编程，公司要制定相应的开发规范和标准，进行页面组件和JS功能模块的积累，测试是个麻烦事。

国外的企业管理软件产品，比如Oracle Call Center、Maximo、Peoplesoft CRM等都采用Applet。JS来做这些表现功能不是不能做，是太复杂了，比如我们一个CRM服务系统，600多个页面，只有一个前台程序员，还是用传统的方式要好些。

个人认为：

如果做Server和客户端完全独立的系统，可以用Web Services，也可以用XMLHTTP，客户端可以采用多种方式。

如果是做纯粹的B/S Web应用开发，XMLHTTP可以做为辅助技术，可以在一些页面中采用，但不会做为主要的技术，我仍会使用传统的开发框架。主要问题在于浏览器技术目前还没有提供组件化的开发支撑，还是一种HTML页面文件输出的编程方式，革命性的改变还要看浏览器的技术这几年会有什么成就。

我对于提高 JS 代码质量的几个主要手段，这些手段已经取得了比较好的效果。我认为这些手段其实适用于任何语言的开发：

1、制订编程规范，严格遵照编程规范做开发，保证代码一致的风格。
当然这些规范也不能太多，其实一个 10 页的编程规范如果严格遵守已经非常有用了。

2、组件化开发，提高代码的重用性。
一再重复使用的表示层控件肯定会越来越稳定，还可以保证页面风格的一致性，提高开发效率。

3、坚持不懈地重构，消除代码的臭味道。
potian 一再强调重构的重要性，gigix 为我们翻译了《重构》这本非常重要的名著。重构如果有自动测试的支持当然最好，不过即使没有（比如有些表示层控件属于视觉控件，很难做自动测试），也应该坚持做重构。我把缺乏自动测试的重构叫做广义的重构，potian 也同意这应该也算是重构。《重构》这本书中介绍的一些面向对象设计的技巧其实还可以成为更加广义的代码结构修改的基础。

刚才看了一点XAML的资料，都没有提到如何开发web应用，都是简单的桌面程序的例子，基本上是XAML描述界面，数据绑定由C#来完成，比较类似于现在dotnet webforms这种模式。

其实要说未来的变数，Flex/XUL的可能性都没有XAML大，毕竟Windows操作系统是主流的Desktop，Windows内置什么支持，他自然有最大的优势。如果Longhorn如期于2006年上市，到2008年，那时候XAML也许会成为主流。其实我最奇怪的是，为什么MS自己都不用XMLHTTP？

robbin，其实这个不是纯技术原因。XMLHTTP 不过是 M$ 顺应 Web 开发人员的要求（从善如流）对浏览器所做的一个小小的改进。XMLHTTP 本身非常简单，非常容易被复制（例如 Mozilla 中很快实现了相同的接口），并不足以将开发人员绑定在 M$ 平台上。XAML 就不一样了，而是一套非常完整的表示层开发框架，一旦拥有，别无所求。这就是我对 M$ 技术策略的理解。

M$ 有很多很好的技术，但是一旦它发现不能达到预期的市场目的，它就会毫不犹豫地抛弃。这种事情已经发生过很多次了。