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

我来给点提示吧。我们在讨论 Struts 的缺陷时我说 XMLHTTP 就是我们的答案。
如果采用 XMLHTTP 与服务器通信，浏览器可以不离开页面通过 XMLHTTP 主动向服务器请求数据，服务器直接把浏览器需要的数据以 XML 格式传给浏览器。基于这样的方式建造一个表示层框架，就可以完全摆脱 JSP 的限制（只需要开发接收和发送数据的 Servlet 就可以了），最大限度地挖掘出 DHTML 的表现能力。这时候表面上是 B/S 结构，实际上是把浏览器当作 C/S 结构中的 C 来使用的。通过适当定义映射关系还可以直接把数据映射到关系数据库。比如我在前台用 JavaScript 发送一个 select p1,p2 from t1，后台就用 JDBC 执行 select p1,p2 from t1，然后把结果返回给我（只是简单地这样说，未必真的这样做）。沿着这个思路可以做成一个支持 JavaScript  的 O/R Mapping 框架出来。这样就变三层结构为二层结构了。以后还会变出什么花样，那你就自己去想吧。

这种想法在很多 Java 开发人员看来是离经叛道，因为三层结构就是他们的圣经（还有什么？MVC、EJB ......）。但是人不能被尿憋死，总要有些想象力才行。我并不认为 M$ 的开发方式都是错的，事实上很多时候我是很认同 M$ 的做法的。

Dlee这种做法我看到过的，也是一个比较大的项目，他们甚至还用JavaScript编写了一个类似Grid的控件，可以列行锁定，利用一个小到不可见的IFrame提交。浏览器界面也全部不见了，几乎就是一个卓面程序。
据我的观察，这种方式在数据交互较少的情况以及用户并发行不高时可以使用。但是数据量一大，相应的XML标签占有很大的百分比，传输的效率就非常低，从JavaScript界面构造XML的过程相当长，并且都是难以测试的代码，服务端计算负载也大大提高，每次都需要解析XML成为实际的业务对象或SQL语句。返回结果也是XML，用Script去解析这个返回结果困难多多，所以决大多数情况下就是一个成功了、失败了之类的提示。用户提交以后等了半天，最后就是一个提交失败、请重试之类的话。本来想改进易用性，结果适得其反。
我自己偏向于WebStar+Swing+RMI来做，如果需要穿透防火墙，最多增加一层HTTP的RMI tunnel。如果需要跨平台，我宁可用CORBA+Delphi+自动更新版本。小型的应用则可以用Hessian这些框架，使用HTTP传输二进制协议，客户端选择的余地也很大。
如果用XUL的话，也可以采用Browser+XUL+HTTP或者Mizilla XUL lib+HTTP，也可以SWING+XUL选择。

对的，我们的应用一次浏览器与服务器交互的数据量不大，数据量大的时候采用在服务器端加 Cache 的方法和异步的 XMLHTTP。其实除了非常复杂的报表，需要一次在浏览器中显示的数据量并不多。
呵呵，他们做的 Grid 之类的东西我们全部都有，加锁也没什么问题。不过我们用的不是 IFrame，IFrame 太落后了（以后我再说说 IFrame 的缺点），我们用的是 XMLHTTP。
我们前台有一个框架来解析收到的数据，大部分情况下性能还是不错的。至于易用性，我可以保证比你看到的那个框架要好。话说回来，易用性还是要看你开发的程度。有人说 VB 做的东西肯定比 Java 做的易用，这个很难说，Java 的东西做好了也是非常好用，甚至 C++ 都可以做出非常易用的框架。我们只要有时间，完全可以自己实现一个类似于 SOAP 的协议，支持比较严格的差错控制。我们目前实现的差错控制有些类似于 Oracle 的做法，感觉已经够用了。至于调试，我们使用 M$ 的 Visual InterDev 并没有感觉到调试起来很不方便啊。Mozilla 自带的 JavaScript 调试器也是很好的。
XUL 的问题是只有 Mozilla 支持，因此我们并不想采用这种方式。我觉得目前 XMLHTTP 是解决表示层问题最简单的技术，它的缺点是有的，但是不足以致命，大部分情况下是可以使用的。基于 XMLHTTP 的开发框架已经越来越多了。

高手如云呀!

我的问题是，从CS到BS，从MS到JAVA，大方向应该是从胖客户端到瘦客户端的减肥过程，你们现在采用的Javascript解决方案，不是又回到原来的老路上了吗？

也许你们的方案现在用起来很好，可是我对它的长远走势持怀疑态度。（没有别的意思，纯粹讨论）

第一次到这里，很高兴看到这么多高手。希望这样的精彩话题能够源源不断的出现。

M$ 从来不相信这一套的。我也不相信将来的趋势就一定会是“瘦客户端”。你对问题的理解有点太概念化了，想想 NC 的下场吧。

dlee，我视图用你所说的方法构建view层，觉得客户端是胖了，但是服务端并没有瘦，因为多了构建xml的过程，我所能感受到的好处仅仅是页面可以动态的从服务断取得数据，而且页面可以局部刷新，这是xmlhttp带来的好处。但是要求局部刷新的地方并不多。这样以来，本来是：
client请求->服务断处理请求，传回回应
这样一个过程，变成了：
client请求->服务端传回html->html中的xmlhttp再次从服务断读取数->server传递xml到客户端－>client

这样多出了一个过程，而这个过程的通信介质是广域网，会不会降低效率呢？

我只是在局部采用xmlhttp。不知道我对你的方法理解是否正确。

呵呵 在去年的时候 我也用XMLHttp做过应用 多少有点心得 和大家探讨一下

如dlee所说"这时候表面上是 B/S 结构，实际上是把浏览器当作 C/S 结构中的 C 来使用的"
在页面上由script发出业务请求，解析返回的xml数据，然后刷新页面的局部
思路就是这样的 但对各位在具体的技术实现时有所不同的意见：

jaqwolf写的：
“client请求->服务端传回html->html中的xmlhttp再次从服务断读取数->server传递xml到客户端－>client
这样多出了一个过程，而这个过程的通信介质是广域网，会不会降低效率呢？ ”

事实相反 为什么采用XMLHttp？
一个首要目的就是为了解决页面频繁刷新的问题 减少client和server端间的数据传输
大家都在网上注册过好多帐号吧？ 就这样一个例子：
假设在注册页面上有这样一个功能，在填写用户名的输入框边加一个'检测帐号是否存在'的按钮
用户一点，页面弹出一个提示，告诉用户他所选择的用户名是否已经存在了

告诉我 如果你不用XMLHttp，用传统的jsp,servlet提交的方式，完成这样的功能有多麻烦
其中一个原因就是，你必须保存用户在页面中填写的其他信息！！！
你即有可能这样做:
写一个action(register.do) 在它的execute方法里面有这样的代码
RegisterFormbean registerFormbean = (RegisterFormbean)actionForm;
//检测帐号是否存在的代码
//假设此帐号已经存在，返回到注册页面，你要做下面的操作
ActionForm request.setAttribute("register",registerFormbean);
然后在register.jsp中再 ActionForm registerFormbean = (ActionForm)request.getAttribute("register");
把用户填写的其他信息都在页面再显示出来 对不？

就为完成一个检测完帐号是否存在的功能 而把用户填写的其他注册信息提交到服务器上再转回来 
真是无用的数据传输 累啊
这一切归咎于http的无状态性 保持会话都依靠Session 无谓的浪费了服务器资源

使用XMLHttp， OK ！
页面用XMLHttp发出个http请求(注意：不需要form提交,这是XMLHttp的优势所在)
写一个servlet ,从请求中取出用户要检测的帐号
String name = request.getParameter("name");
AccountsBO bo = getAccountsBO();
boolean exist = bo.chectAccountExist(name);
返回个xml串 <xml>....<exist>true/false</exist>....</xml>
页面一解析xml不就知道了 然后该干嘛干吗 ：）

我这只举了个简单的例子 你完全可以用其他的办法来避开这个问题
但是用XMLHttp 一切是那么简单