|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-03-16
potian写的：
"据我的观察，这种方式在数据交互较少的情况以及用户并发行不高时可以使用。 但是数据量一大，相应的XML标签占有很大的百分比，传输的效率就非常低，从JavaScript界面构造XML的过程相当长， 并且都是难以测试的代码，服务端计算负载也大大提高， 每次都需要解析XML成为实际的业务对象或SQL语句。 返回结果也是XML，用Script去解析这个返回结果困难多多，所以决大多数情况下就是一个成功了、失败了之类的提示。 用户提交以后等了半天，最后就是一个提交失败、请重试之类的话。本来想改进易用性，结果适得其反。" “从JavaScript界面构造XML的过程相当长” 不错 从XMLHttp发送请求 需要用script来构造XML串 “服务端计算负载也大大提高，每次都需要解析XML成为实际的业务对象或SQL语句。” 这我就不明白了，服务器端为什么要解析XML成为实际的业务对象或SQL语句 ？？？ “返回结果也是XML，用Script去解析这个返回结果困难多多” 不要使用Script来解析返回的XML，请使用xslt 
用Script去解析,太麻烦 调试困难 “本来想改进易用性，结果适得其反” 这是不当使用 不是XMLHttp的错 使用XMLHttp,能最少地减少数据的交互 如何正确使用 需要xmlHttp,Script,xml和xsl的恰当配合 |
| 返回顶楼 | |
|
发表时间：2004-03-16
dlee写到：
“通过适当定义映射关系还可以直接把数据映射到关系数据库。 比如我在前台用 JavaScript 发送一个 select p1,p2 from t1，后台就用 JDBC 执行 select p1,p2 from t1， 然后把结果返回给我（只是简单地这样说，未必真的这样做）。沿着这个思路可以做成一个支持 JavaScript 的 O/R Mapping 框架出来。 这样就变三层结构为二层结构了。以后还会变出什么花样，那你就自己去想吧。 ” 这种方法完全不可取 三层结构的结构是完全有必要的 前台的页面里的内容 对用户完全可见 谁在前台用JavaScript 发送一个 delete from .... 活活 Script 发送的只能是业务请求 不能是业务的具体实现 但提到数据库 有一个便捷的方式从servlet返回XML到页面 比如说查询 生成查询列表 过去需要从resultSet中取出数据 生成实体类对象 然后从实体类拼成XML串 oracle数据库支持从结果集直接生成XML串 直接返回到页面 呵呵
|
| 返回顶楼 | |
|
发表时间：2004-03-16
使用IE里的XML数据岛 加上上面说的从oracle结果集直接生成的XML串 构造简单的应用很简单
但不推荐 ：） |
| 返回顶楼 | |
|
发表时间：2004-03-16
lu_icicle 写道 jaqwolf写的：
“client请求->服务端传回html->html中的xmlhttp再次从服务断读取数->server传递xml到客户端－>client 这样多出了一个过程，而这个过程的通信介质是广域网，会不会降低效率呢？ ” 事实相反 为什么采用XMLHttp？ 一个首要目的就是为了解决页面频繁刷新的问题 减少client和server端间的数据传输 大家都在网上注册过好多帐号吧？ 就这样一个例子： 假设在注册页面上有这样一个功能，在填写用户名的输入框边加一个'检测帐号是否存在'的按钮 。。。。。 页面用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 一切是那么简单 你所说的这个例子的确很能反映xmlhttp的好处，但是这个好处我也曾经提到。问题不在这个地方，问题在很多页面不需要局部刷新，或者没有很强的连续性的时候－也就是不需要保留状态的时候，xmlhttp＋js作为整体的view-tier方案就优势不明显了。所以我说只是局部这样做。 |
| 返回顶楼 | |
|
发表时间：2004-03-16
dlee写到：
”我们前台有一个框架来解析收到的数据，大部分情况下性能还是不错的。至于易用性，我可以保证比你看到的那个框架要好。 话说回来，易用性还是要看你开发的程度。有人说 VB 做的东西肯定比 Java 做的易用， 这个很难说，Java 的东西做好了也是非常好用，甚至 C++ 都可以做出非常易用的框架。 我们只要有时间，完全可以自己实现一个类似于 SOAP 的协议，支持比较严格的差错控制。“ ”前台有一个框架来解析收到的数据“ 我是使用XSLT 我觉得每个页面都有自己的数据和表现样式 所以每个页面都有配套的XSLT 如何用一套的？ 请指教 ”我们只要有时间，完全可以自己实现一个类似于 SOAP 的协议“ 不错 我们使用XMLHttp就是用它发出Http请求，用XSLT解析xml的 XSLT就是‘自定义的SOAP语义’ 呵呵 我们完全可以用Script和XMLHttp做一个WEB框架,一个新型的UI 呵呵 扯远了 和”为什么 Ofbiz 没有使用 Struts “ 没什么干系了 ：） |
| 返回顶楼 | |
|
发表时间：2004-03-16
jaqwolf 写道 你所说的这个例子的确很能反映xmlhttp的好处，但是这个好处我也曾经提到。问题不在这个地方，问题在很多页面不需要局部刷新，或者没有很强的连续性的时候－也就是不需要保留状态的时候，xmlhttp＋js作为整体的view-tier方案就优势不明显了。所以我说只是局部这样做。
优势还是有的 这个问题 在于如何使用Script来调用XMLHttp的了 XSLT在其中的作用也很关键 整个这个框架的设计就在于次 说明白也不复杂 但在这敲字一时说不清楚 以前写的总结文档不在手边 回头找找 |
| 返回顶楼 | |
|
发表时间：2004-03-16
dlee 写道 M$ 从来不相信这一套的。我也不相信将来的趋势就一定会是“瘦客户端”。你对问题的理解有点太概念化了，想想 NC 的下场吧。
dlee有没有兴趣谈谈对于thin client的想法啊？我也不是很同意这个趋势，因为市场已经有了很多功能强大的client，即使考虑历史原因也不可能一统天下，不过我的看法可能不是很深入，抛个砖，希望有人讨论。 |
| 返回顶楼 | |
|
发表时间：2004-03-16
msn explorer 非常典型的thin clinent 趋势
我很看好 thin client 当初转型 thick client 我不知道是什么原因，如果是为了降低复杂度，那么由于采用好的结构，thin client的开发也不必thick复杂。 |
| 返回顶楼 | |
|
发表时间：2004-03-17
dlee 写道 JDBC 过于低层了，如果永远只在如此低的层次上工作，那么复杂的大型项目的完工就遥遥无期了。好在 OOP 给我们提供了无限的封装能力。JDBC 之上有 Hibernate、JDO，还有 Ofbiz 中 Entity Engine 实现的 OR Mapping 框架。这些开发框架极大地减少了开发的工作量。这些框架的目标就是要在大部分场合完全替代 JDBC。然而我觉得有些遗憾的地方是 Hibernate、JDO 的抽象层次仍然没有上升到业务对象的高度（所以它们不能够作为单独的解决方案，而只能作为更大的业务框架中的嵌入式组件）。业务分析和软件设计在国外是分的比较开的两个领域，分析领域有很多模式（分析模式），最后得到是分析对象，这些分析对象是直接与业务相关的，也是商务人员比较容易理解的。设计领域也有很多模式（设计模式），最后得到是设计对象（差不多就是计算机中真正的对象）。但是目前从分析对象到设计对象的映射还有较大的空隙（gap）需要填补，填补了这个空隙，软件从需求收集、业务分析到设计、开发、部署、测试的全生命周期就能够以一种无缝的方式结合起来。Borland 整合了 Together 和 JBuilder 后可能会有一个比较好的方法。我还没有试用过 Together for JBuilder，你可以看看其介绍。
解决业务问题的业务框架有很多，IBM 兜售的解决方案中就有面向业务的框架，比如以前的 E-Commerce Suite（现在好象叫 WebSphere Commerce Suite 了）。开源的业务框架我只用过 Ofbiz，感觉比较好，你可以找些资料看看。 http://www.ofbiz.org 我从来没有说过 Hibernate 是万能的这样的话，所以别安在我的头上。 dlee兄,我有一个基本的问题希望你能够给出您的意见? 到底用了hibernate和不用hibernate和用DAOpattern+JDBC+SP(optional),不是xMP的Entity Bean(这是在大多数的情况下把简单的事情复杂化了,n倍的,所以不予考虑)对在项目的saving有很大吗? 你有没有实证的例子?(1/6 of original time, 1/3 or even more?) |
| 返回顶楼 | |
|
发表时间：2004-03-17
lu_icicle 写道 jaqwolf 写道 你所说的这个例子的确很能反映xmlhttp的好处，但是这个好处我也曾经提到。问题不在这个地方，问题在很多页面不需要局部刷新，或者没有很强的连续性的时候－也就是不需要保留状态的时候，xmlhttp＋js作为整体的view-tier方案就优势不明显了。所以我说只是局部这样做。
优势还是有的 这个问题 在于如何使用Script来调用XMLHttp的了 XSLT在其中的作用也很关键 整个这个框架的设计就在于次 说明白也不复杂 但在这敲字一时说不清楚 以前写的总结文档不在手边 回头找找 多敲几个字，呵呵，我很有兴趣听听啊。如何使用js来调用xmlhttp，方法我也知道，如何设计，想听听你的经验：） |
| 返回顶楼 | |
