论坛首页 AJAX版 AJAX

现在对于一个项目中如何选用AJAX值得讨论

浏览 1220 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
最后更新时间:2008-01-20
在web2.0的时代,ajax的框架实用性可以说是到了极致。但是如果真正要做一个企业级的AJAX,个人认为还是要认真对待。

对于目前的EXT,DOJO,DWR等等都是大家津津乐道的框架。这几天我受到一个朋友的启发,确实也在考虑这个问题:
学习成本的考虑,我们该如何选择我们需要的。

1.DOJO基本是IBM极力推荐的,而后使得DWR也被收编其中。DOJO应该是一个“full stack”,也正是由于它的庞大让人觉得有个疑问:它是否适合我们当前的项目或者产品?DOJO的速度在一定程度上也是个大问题。

2.EXT,不能否认他是一个好的框架。而且炫目的view让任何一个人看到都不会忘记。于此同时它给我们当前的项目带来的益处又有多少?如果大家确实是在使用一个大型的系统能否很高效的使用它?它的速度是否是我们期盼的?



或许我对AJAX还不是很了解,才想得到大家的解惑。
   
最后更新时间:2008-01-20
什么叫"企业级的AJAX",我不太了解,如果你是说RIA,那可能吧,但是js xhr目的其实是丰富UI实用性,表现力的东西当然也很有用,但是有多大用,不了解
   
0 请登录后投票
最后更新时间:2008-01-20
可参阅:
《为什么选择Ext作为表现层解决方案》
http://blog.csdn.net/aliang19117910/archive/2008/01/03/2022993.aspx

和本人的《像了解爱人一样了解ExtJs》
http://www.javaeye.com/topic/128596
当然,小弟是EXT派了 

引用

以下来自InfoQ和 Sitepoint的两篇文章的节选,前者讨论了JavaScript框架的选择标准,后者详细解释了Ext的优势。我想两个文章的节选片段已经为我们选择Ext作为表现层解决方案提供了足够的理由。


引用
为什么选择Ext

Ext Comes to the Rescue

In a nutshell, Ext delivers just what we need -- a stable and uniform JavaScript platform for building rich web applications. Building on the Yahoo! UI Library, Ext has looked very promising for some time. When version 2.0 was released last week, however, the library matured into possibly the most robust JavaScript library available for developing rich web user interfaces.

There are a few alternatives out there of course, such as Dojo and the Yahoo! UI Library, but there are a few key points that, when combined, make Ext stand out from the crowd. These points include:

    * Ext is very fast. Performance is often a problem when programming JavaScript.
    * Ext is implemented in a 100% object-oriented, well structured, consistent way. This makes the library fast to learn, and the code easy to read and understand.
    * The modular implementation with its consistent base makes the library easy to extend.
    * All Ext elements (widgets) are ready for use. In contrast to many other libraries, the widgets are usable as they are, with pre-defined styles, settings, and behavior. Still, all elements are fully customizable and can be themed if required.
    * The Ext developers are extremely dedicated and competent, and have an understanding, and most importantly an interest, in users' needs. Ext documentation is thorough and full of working examples.
    * The Ext community is very active, and the tone is generally very positive.
    * Ext can be used both under a free and a commercial license.
    * Last but not least, Ext looks very slick!

Some (or maybe even all) of this is true for other libraries as well. I don't pretend to suggest that there aren't other excellent alternatives out there, and you should investigate all options before deciding to stick with one. However, in my experience Ext gives the best overall impression, which is why I decided to run with it.
   
0 请登录后投票
最后更新时间:2008-01-20
像楼上朋友说的,我也看过。不过不足以说明问题的本质
   
0 请登录后投票
最后更新时间:2008-01-20
在下觉得,选择一个框架的标准应该是参考资料的丰富程度,和社区的活跃程度。

在这点上来看extjs似乎比dojo更活跃,资料也更丰富,单说发布版本里的examples和docs,extjs就比dojo好许多。

在下感觉extjs比dojo更容易获得参考资料和实例,不过也可能是因为在下过多关注extjs的原因,但是介于半年前实用dojo-0.4.3的经验,实在感到dojo的参考资料如此匮乏,不知道如今1.0.2是否摆脱了当日想找啥都找不到的困境。
   
0 请登录后投票
最后更新时间:2008-01-20
"像了解爱人一样了解ExtJs",有意思,由此可见是sp42对之爱太深了,但是这种比喻不贴切。

对于一般的项目团队而言,了解Ext的过程应该更像是追求女友。应该有一个由浅入深的了解过程。如果合适,谈婚论嫁后再像爱人一般,携子之手,与子偕老(伴随项目开发的日日夜夜一同度过)。

这个过程,包括了两个方面:对项目团队的评估和对Ext的评估。

首先有自己的项目需求,是需要开箱即用的widget,还是支撑自定义开发组件的底层技术。企业应用通常需要在界面处理大量的列表数据,只要少量的编码就能使用,同时支持提供大量自定义的接口扩展功能,Ext的组件是很不错的选择。同时,性能是最大的考量,Ext在这一方面已经做得很出色了。

然后是了解项目团队的资源,团队是否有相应的资源(团队成员)掌握相应的AJAX技术,对AJAX的掌握程度如何,对这项技术的付出的具体风险等等。

Ext的高性能,面向对象API风格,开箱即用的widget,活跃的社区等等优势,都是值得团队选择表现层框架时认真考虑的。

在企业应用中,对于Ext的评估,建议使用务实的做法,从组件的使用入手,先使用DataGrid,经过一段时间的使用和评估后,项目组成员对Ext也慢慢熟悉,然后慢慢引入Tree,Layout等组件。这个过程是渐进的,增量的。原有的技术应该是一个逐步迁移的过程,通过这种方式逐步统一表现层框架。

如果你还在犹豫,那么这种“渐进的,增量的”的方法是值得推荐一试的。不要想着一步到位成为爱人,这是不现实的,谈恋爱是需要一个过程的。开始了解了,你慢慢就会有方向了。
   
0 请登录后投票
最后更新时间:2008-01-21
ls的朋友的某些提议还是值得学习下,呵呵
   
0 请登录后投票
最后更新时间:2008-01-21
喜欢mootools
   
0 请登录后投票
最后更新时间:2008-02-20
(注意这里针对ajax的讨论限定了国内的企业应用开发这个范围)

企业应用开发,大部分项目的首要目标是实现用户的业务目标,而不是提供一个绚丽的用户界面,明确这点很重要。

作为开发商而言在界面上多一分付出并不意味着合同额会提高多少.相反,提供复杂的用户界面却意味着开发周期的延长,

更多的Bug,更复杂的程序需要去维护.目前的dojo或者extjs等等都还没有贫民化到易于维护的状态。反而,与Java,C#等具有编译期间检查的
语言相比,javascript天性随性的特性很容易导致项目代码一团乱麻,难以维护。

Ajax被炒作得过热了,需要我们冷静看待,慎重选择.

总体来看
a.与以前的jsp标签开发方式相比,完全采用Ajax框架来开发界面,需要更复杂的编码方式,技术水平更高的开发人员。
开发人员需要具备javascript,xml,jason,extjs或者dojo lib,设计模式等技术才能写出高水平(易于维护)的代码.
尤其是javascript,规划不好,很可能就是一场维护的噩梦。

b.从系统架构来看,完全采用Ajax框架来开发界面,由于前端表现能力的增强,意味着有些职责很可能被轻易的转移到前台,
比如页面的流转,在Struts 1.0时代页面流都是由Struts框架来做,现在前端有能力完全负责页面流转的控制,复杂性
转移到了前端。这些对于系统的重用带来了新的需要考虑问题。

还有...

建议理性对待ajax,该用的地方用,不该用的地方别用,无关紧要的地方试用。

该用的地方:比如庞大的菜单显示、需要异步请求的地方、服务器长时间计算需要给用户界面提供进度反馈的、大量显示grid的

不该用的地方: Form 录入、不需要异步请求的、原来项目已经解决得很好的地方

试用的地方:比如权限管理等可以尝试使用,以评估是否可以大规模使用。
   
0 请登录后投票
最后更新时间:2008-02-20
个人感觉在企业应用中大规模使用ajax是在冒险...我们用dojo已经掉坑里了。
   
0 请登录后投票
论坛首页 AJAX版 AJAX

跳转论坛:
JavaEye推荐