关于基于 XMLHTTP 做表示层开发的探讨

会的人为什麽不愿意发言！
我是这样做的，凡是 IE--->Java的时候，只是传递很短的参数，比如username, forumid等信息。 所以根本不用考虑传递长参数的情形，就像你说的传递XML DOM我是不会这麽做的。
而Java--->IE,则是传递比较大的数据，比如整个DOM 对象，Javascript有直接的方法可以Load这个 dom,在解析就可以了。
至于从IE到你的程序，有必要传递整个大的dom对象吗?

真不明白楼上在抱怨什么,其实有人回答了呀(http://forum.iteye.com/viewtopic.php?t=4643)!!
send()方法如果是用post的话,没有长度问题呀.

大的有可能喔,例如:考试.
在一个页面中就有多选题,单选题,问答题等.
当然如果用request.getXXXX()也可以,但并不是很直观,而且可能会有一些很难发现的错误(特别是数据很容易搞乱).
如果用一个dom的话,就比较好(但可能这个dom会比较大,当然不是达到几M的数量,可能length很大).
还有就是用dom传送二进制数据会比较大(这时是size比较大)(例如同时上传数张图片,或者music等文件的话..)

多谢，我的意思是如果从客户端吧数据传到服务器端还有必要用XMLHTTP吗？我认为没必要吧。因为如果是从服务端到客户端 ，如果不用 XMLHTTP的话，那麽原则是 DataModal-->O/R-->Control-->FormBean---->taglib
如果用了XMLHTTP,可以简化为 DataModal--->页面（javascript），这是为了简化开发，就是也面直接向持久层请求数据。
但是提交数据的时候，还是要经过一些DAO层的处理比较好，你从也面直接交给持久层，

1.从速度上很慢（我测试的时候，凡是用了XMLHTTP的时候有个通病，点击button后，按钮会定住3 s，然后才有反映，不同于用 jsp页面Post 数据。
2.页面的逻辑不一定符合业务要求把，如果你全部在页面用javascript转型，速度更慢，提交给服务器就方便多了。
你是怎麽做的？

的确,在很多时候没有必要进行send(dom),一般都是直接在url后面加上参数就够了,除非上面提到的几种情况(特别是上传多个文件,用xml上传二进制会非常方便,而且不用其它什么组件(只要客户端支持就够)).

SunOne Server:
不知道你的测试的数据有多大呢??是什么数据呢??
一般都不会有3S那么久(如果只是提交一些普通数据的话).
如果你可以的话,用异步提交吧(当然要你的操作可以异步进行),你就不用等待该操作结束就可以再操作了.

Cordys公司产品BCP, WCP就是完全采用xmlhttp+soap的形式来开发表现层.
xmlhttp开发的不足之处在于ie的版本. 不同的版本效率和稳定性差别挺大的.

b/s方式的每次提交刷新，确实比较烦人。很多数据，如果客户端能够保留一段，会极大的提高效率。以前的C/S方式的没落可能是由于客户端维护的成本，当然现在还有不少c/s的应用。但我一直认为b/s开发的工作量是增大了。如果有一个统一的客户端（浏览器），统一的数据表示方式(XML), 通过客户端的处理来展现数据，以统一标准进行数据交互，工作量会降低很多，当然前提是这种处理的实现很方便，而且客户端能够保持数据。以前看过微软做的一个项目，使用xmlhttp, 确实比较方便，而且没有整个页面数据的全部刷新。如果xml-http能够与application server结合在一起，完全免去有些琐碎的xml操作，我想这种方式确实有生命力。肥客户端如果只是负责表示及表示逻辑的处理，不见得比瘦客户段差。

dlee说:我们前台有一个框架来解析收到的数据，大部分情况下性能还是不错的。至于易用性，我可以保证比你看到的那个框架要好。

我疑惑dlee没有看到potian看到的框架是什么样子,凭什么就说比potian看到的那个框架要好!不妨给个应用的演示大家看看,也让大家学习学习,如果是真好我倒是不介意如此的说法.

冒犯了大虾dlee,不要拿板儿砖拍我.

我目前在写一个框架,基本也是xmlhttp+javascript的思路,参考了.net中DataSet的思路,客户端将接受到的xml数据集中解开与客户端javascript写的组件绑定,数据变更的过程记录到xml数据集中,服务器段接收到xml数据集后解析成SQL语句,因为xml数据集中包含了原数据,因此大多数情况下可以采用默认的解析机制,不用程序员编写解析的代码.现在已经具有了雏形,但还不完善,主要是在多表更新的问题上数据的封装和解析太复杂,难以实现.