ajax框架与服务端框架

zhaow8810
有了ajax，客户端可以访问静态的带有javascript的html页。 页面的所有表单元素数据都通过 XMLHttpRequest请求得来，这样还需要有服务器端控制层吗？胖客户端有什么优势啊？
xf 2006-11-21 05:53
ajax是不可能打败胖客户端的，同样胖客户段也不可能打败瘦客户端，只能说各有其用，对于企业管理软件来说胖客户端架构优势实在太大了，你ajax费尽九牛二虎之力做的事情，对于胖客户端来说只是他固有的功能，胖客户端唯一的劣势无非就是一个部署更新，这个你可以看看现在的智能客户端，这方面完全可以做的比B/S好上许多倍。

同时不要盲目崇拜ajax，他有好的也有不好的一面，小规模使用是可以提高表现层的客户体验，但是如果拿来做一个非常复杂的业务系统，那就有的苦头吃了，国内这方面具我所知"锐道"比较强，号称胖B/S架构，采用了大量的ajax，结果用他们做出来的业务系统，共同反映很慢，同时对于ie来说这个东西也不稳定，升级是一个很大的问题。

所以只能说各有千秋罢了，不然微软的.net也不要搞什么win form了。呵呵。

banq 2006-11-21 09:18
言之有理，目前在sun公司java.net企业应用目录中有一个大概是ajax4这样项目，主要目的想做到力争不写一点javascript代码就能用ajax，因为javascript是一个过程性语言，而我们现在都进入了oo语言了。
zhaow8810 2006-11-21 09:49
在这里听到的答案往往都会有解惑的感觉。确实值得称道。
听了以上二位的意思我觉得应该是这样用ajax技术。我们可以用但是要建立在一个良好的系统架构上用这个东西，显示一些大家所期望的效果。但不能完全的做成纯ajax系统如果html+js+业务。原因可能有很多。技术、维护、安全、速度。
谈谈ajax实质！
客户端首先从服务器请求页面。服务器返回内嵌 JavaScript 代码的 HTML 页面。然后 JavaScript 代码从服务器请求更多的数据（通常使用 XML）并动态地更新页面。
我们可否在中间做些手脚来均衡一下。客户必然还会请求服务器。服务器返回的页面是由现有的传统框架所生成。（而不是静态的Html+js)然后js代码可以从服务器请求数据（xml格式可实现页面节点动态刷新）跳转页面工作由传统框控制层处理并且搞定权限安全等一些拦截工作。这样是否是当前web的需求那？
banq 2006-11-21 10:58
>跳转页面工作由传统框控制层处理并且搞定权限安全等一些拦截工作
是这样，ajax与控制层的关系，在scope粒度上不同的，也是事件模式的不同，事件模式中常有主动触发调用和reaction自我触发两种，控制层是为了应付主动触发调用，进行一些大scope范围内大的主要页面流程跳转；而ajax是一种reaction自我触发为主的模式，通常可用在一个大的主要页面范围内自我激活其他小页面的调用。

从事件模式角度看，主动触发调用和自我触发这两种模式都有应用范围，没有随替代随的问题，具体技术总是服从应用模式的。

当然，ajax也可能发展出响应主动触发调用模式，但是安全性等问题这时就是首要问题，安全验证一定需要服务器端实现，包括控制层Web资源验证，以及业务层的组件构件方法调用验证等。

btw: 当出现一个新技术时，我们在激动之余，就要以模式观点来看待，就不会走极端，泰然处之，也不会有压力紧张感，感觉那么多技术要掌握，知道某个新技术是哪种解决方案，哪种模式，以后在遇到相应场景问题时，再进行具体研究也不迟。

banq 2006-11-21 11:18
另外，我认为Ajax不会对服务端框架结构产生大的影响，服务器端还是需要表现层、业务层和持久层框架，还是需要使用Evans DDD面向对象的方法来建模，实现Domain Model和服务，我们的业务重点还是在业务层的Domain Model。

Ajax相当于延长了表现层的范围和触角，丰富表现层框架，我们还是可以将Ajax和JSF或struts/Tapestry结合使用的。

Ajax对于客户端和服务器端的大数据量传递提供了异步处理方式，从而我们可以利用用户在浏览已有数据的空闲时段，悄悄地将下一批数据从服务器端拉到客户端。

在服务器端，事件处理都分同步和异步，那么这种区分也体现在客户端是很自然的结果，提供了展现丰富界面效果的强大技术支持。重视客户端有时可能比重视服务器端更有效，更能说服客户，这是中国实情啊。

banq 2006-11-21 11:40
不好意思，再补充一点，想到说到：
AJAX解决了过去困扰我们B/S结构下服务器向客户端“推”的功能，浏览器过去只能从服务器拉信息，我们使用浏览器频繁整个页面全部不断刷新方式来从服务器获得一些可能随机立即发生变化的信息，现在可以不必这么痛苦，委托ajax在后面异步不断地从频繁服务器的侦测。在表面上更好地解决了以“拉”方式实现服务器向客户端“推”的效果。
zhaow8810 2006-11-21 12:07
这么说无非是说明，不要盲目的追寻新技术。要分析要理解要权衡
结果那？
结果无非是一道选择题。
A.多用ajax技术使得客户端有一定的逻辑处理能力。（页面数据都由js请求DOM解析而来）
B.适量用ajax技术结合当前成熟的表现层框架。（页面主要数据由表现层框架得来部分数据可以异步请求后台通过dom解析xml得来）
mythmoon 2006-11-22 19:54
---小规模使用是可以提高表现层的客户体验，但是如果拿来做一个非常复杂的业务系统，那就有的苦头吃了，国内这方面具我所知"锐道"比较强，号称胖B/S架构，采用了大量的ajax，结果用他们做出来的业务系统，共同反映很慢，同时对于ie来说这个东西也不稳定，升级是一个很大的问题。

__>
这样的论断我很难认同，不知道楼主有没有用过dorado5,实不想瞒，我本人就实dorado的工程师，dorado5在运行速度上在页面速据量不大的已经和静态页面相差无几，我们有在线copy2000条数据的例子。
业务逻辑复杂，影响数据恐怕不是展现的问题，更多的是servlet处理慢！


――――――――――――――――
不是做广告就事论事！

zhaow8810 2006-11-23 02:15
这里有人用ajax框架做页面的全部控制层吗？谈谈经验。郁闷过、还是欣喜若狂过……
xf 2006-11-23 07:27
这位老兄也不要见怪，很多我这里指的是复杂的表现层，不可否认，我见过你们的产品，做的是非常牛，也不可否认，国内的大多数变态表现层的需求你们也基本都可以搞定。可是有些东西我觉得你们自己肯定也不得不承认，毕竟js，html的效率肯定比不过2进制对象，同时我不知道你们对于js的内存处理如何，反正ie对于js的内存管理肯定比不上.Net的虚拟机以及GC， 很多地方使用完毕后还是需要主动释放的。比如最简单的例子，你做一个可以编辑的Table,这个我看过你们的例子，是很强。我们公司也有类似的Web组件，也是可以配置列单元格编辑器，也可以配颜色，配演码，不过在开发过程中就遇到很多问题，这里我们不谈数据整合这层，只谈如何控制HTML的Dom对象交互，主要问题在于当数据量到一定程度，整个表单控件会很慢很慢，最后发现原因是js对象没有释放。类似这样的问题太多了，不敢保证一个很大的产品每个类似的地方都不出错。而对于胖客户端组件而言，这些都不是问题，至少性能效率上要比Js的表单组件稳定的许多。我们公司的产品一个用户界面有20多个Tab页，上百个控件，还有几十个Table，里面乱七八糟的页面控件交互控制逻辑多的一踏糊涂（比如第一个页的一个控件，要求能控制第二个Tab的控件的Enable，disable），当然这个是用户的需求，试问用你们锐道的产品来做，我不说别的，就打开一个页面，你估计要多少时间。如果做一个查询，装载一批数据又要多少时间，这里还不谈复杂的焦点问题。我想焦点问题你们肯定也不是第一次碰到吧，尤其是要在表单内控制焦点问题，我们公司的客户可是要求全键盘操作阿。这些问题都太多啦。我就不一一列了，当然，在Web方面，你们可以说做的是非常出色。这点我不得不承认，只是说有些系统比如我说的这种表现层要求非常高的复杂系统，我看兄弟你们做起来不见得开心吧。用户用起来也不见得开心，呵呵。
xf 2006-11-23 08:04
BTW:偶现在的公司是德国人公司，公司也在搞自己的架构，但是好像对表现层不怎么感冒，认为很肤浅的东西，看不起我们中国人，觉得他们用EJB之类的中间件很牛，其实个人觉得，他们这帮才是一帮农民，要有一个非常好的表现层架构，难度之大超出想象。这点我想这里的各位都应该有一个清楚的认识吧，如果将表现层开发难度降到最低，一直是一个在讨论的话题。

锐道的朋友不知你有没有听过common control这套WEB组件，我们公司（德国）现在自己不做表现层组件了，就用的他们的，我看这套组件连你们的1/10都不如，他们估计连ajax为何物都不清楚，连一个表单的排序都要到后台去做，不过就这样的东西，价钱也不低啊，我看你们有兴趣可以去看看这个组件。

mythmoon 2006-12-04 16:28
> 这里有人用ajax框架做页面的全部控制层吗？谈谈经验。郁闷
> ⒒故切老踩艨窆?

你可以到这篇文章看看
http://61.151.239.187/bbs/forum/viewthread?thread=658

对使用AJAX开发有帮助。

zhangyafei 2006-12-17 12:31
在伟大的技术也是为了实现两个目标：
1、满足商业用户的需要，降低成本
2、满足最终消费者的需要，给消费者以最佳体验

富客户端目的是可以满足后一种需要，但在提供一致体验来说，并不是所有的客户端技术都能实现的。

另外，这里所说的胖客户端和富客户端是有区别的，胖客户端是指客户机模式，富客户端是c/s b/s的中和。

欢迎访问我的blog：http://zhang-yafei.spaces.live.com/

xf 2006-12-18 23:28
This debate regarding B/S and C/S makes no sense. If we have chance, why don't we find out a real case including a lot GUI fuctionalities that we might encounter commonly and implement it respectively by various GUI technologies, no matter what the technology is. Then, I suggest we publish result including source code, data base, time sheet and something else.
After all, we must put our idea into pratice.
Of course, the precondition is that we have enough time. If we have, why not? Banq, could you consider that please?