@abent
兄台也在开发Flex程序么,好的很啊,有机会多交流。Flex程序的架构确实给我们提出了新的挑战,客户端C/S,整体又要B/S,然后还需要能脱离B/S单独转C/S,模式很新。我倒是听说有一些框架可用,不过目前还不打算用,还是想自己先探索一下,也可以理解的深一些。
re: 慎用AJAX框架 weidy 2007-07-08 23:02
@abent
不是,哪家公司也不重要,对吧.
re: 深入理解RIA(下) weidy 2007-01-21 19:14
a. 其实已经打起来了,不过并不是微软和Adobe之间,Adobe至少在口头上是不猝微软的,他们目前最大的敌人是开源。Laszlo和Flex去年就火拼过,前者已经避Adobe作出了很多免费的举动。
b. 互联网是个开放,包容的空间,要想占领可不是那么容易,基本还是要延续现在百花齐放,大家并存的状态。收费也有收费的好处,不能简单的认为就是免费的好。
C. 至于微软,去年年底宣布了转型搞互联网,不过我想就算桌面的霸主要想在互联网里立足,也还是得先习惯互联网里的规矩,要不只能是越搞越衰。
re: RIA,敢问路在何方? weidy 2006-12-14 17:22
@zhang-yafei
非常感谢您的解答!我想这个问题已经很清楚了。我的link您尽管加,写出来就是要和大家讨论,您的Blog我也会经常访问的。
此外我打算有空的时候也继续写一些关于RIA和Flex的article, 毕竟我用Flex也有一段时间了,希望能继续和大家交流,得到大家的指点。
re: RIA,敢问路在何方? weidy 2006-12-13 10:10
@zhang-yafei
非常感谢张先生指点,您的blog我已收藏,会慢慢阅读。AJAX确实有些炒的成分,我很赞同这一点。
我对RIA的理解还比较肤浅,有很多问题还希望能向大家请教。
1. 我理解的RIA是在客户端丰富的数据模型和丰富的界面,过去我们总是用Javascript来在客户端处理一些逻辑,从而“客户端逻辑减轻服务端逻辑所造成的负载”;此外很多Javascript的组件(如dojo)来实现一些很不错的界面效果;从这两方面来说用XHMTL+CSS+JavaScript实现的富界面程序(不是说AJAX,还是用这种XHMTL+JavaScript手段)能否看成RIA的一种?
2. 如果 “RIA的实质是用客户端逻辑减轻服务端逻辑所造成的负载,并在客户端营造客户机模型” ,那是否意味着,现有HTML(Javascript) 的能力很难胜任,或者说不适合RIA的工作?
re: 郁闷,高级开发员居然不喜欢写文档 weidy 2006-12-12 10:18
看上去你是个新上来的领导吧,不是我批评你,“完全一致、具体到类和公用方法”的要求十分的蛮横和武断,证明你没有真正理解项目组织的实质,没有理解文档是做什么的,应当在项目中承担什么样的作用。
你被抵制是情理中的,一方面你这样的要求过于理想化很难真正达到目标,另一方面也是扬短逼长,对人力物力资源的浪费,文档的维护性和表达能力远不如代码,代码里一个通用约定,几十个字母能说清楚的问题用文字去表述要写多少字(还不考虑有些程序员对写文档有天生的厌恶)?就算你说的要从面向未来的角度,那你将来要同步文档和代码,又需要多少的投入, 有多少实际的可能?算了,这个问题也不多说了,等你多碰几次壁,自然就领会了。
re: 乖乖,sun终于启动开源进程了! weidy 2006-12-07 09:52
对SUN未必是个好事情,这是逼大客户发展他们自己的jvm。 就我看来,要开源5年前SUN 就应该将jvm开源,现在再开源,两边不是人。
re: 慎用AJAX框架 weidy 2006-12-05 16:35
嘿嘿,想不到一年前的一个老贴子,一直有人来留言讨论这个问题, 我也就再来罗嗦几句吧。
我是一年前写这个帖子的,当时的想法是告诉大家是想告诉大家一些AJAX负面的东西,贴出发出来后就和“读书、思考、生活”进行了激烈的讨论,应该说我文中所提的并不全对,但我想表达的东西是很明确的:AJAX技术是趋势,应当积极学习应用,但要注意其缺点和可能引发的问题,不能过度使用。
我在原文中用来举例的系统是一个数十乃至上百人的团队做了7、8年的老产品,有历史遗留问题,并不具备普遍性,所以咱们有很多高手不已为然,认为我说的那些问题只有过去才有。但仔细想想这个例子还是能说明些东西,这些问题真的就没有了么,你使用的框架真的能把他们都隐藏起来么,还是你的应用还比较简单,这些问题还没有构成麻烦呢?
过去一年中我也在自己的和单位的项目中大量的使用AJAX,对AJAX的理解也提高了很多。比如在公司去年启动的一个的项目中,来源于MQ和web service的数据都送到一个主要基于DOJO实现UI的系统中和用户交互,仔细统计后我发现这个主要由老外实现的系统的60-70%的代码量是用在写 javascript 来完成交互效果,大部分的业务逻辑都是接收到JSON数据后在客户端完成的,而需要指出的是在传统开发模式中,这些工作其中的很多以前恰恰是可以由框架完成的!
也就是说,目前AJAX框架依然没有达到我们需要的那么强大,还有很多功能需要我们自己来实现。那么在这个时候,请您,一个绝世的技术高手,注意一下当你用AJAX来实现一个功能时,还是可以扬长避短,如果服务器端或者说传统的方式就能做的简单功能,就不用弄需要在IE6, IE7, FireFox, Mozilla, Opera等等上去全测一遍。当然,这仅仅是善意的提醒,绝不敢对高手们说教。此外,IE和FF下的JS调试工具我用过不少,能为解决问题提供些帮助,但和传统的类调试还是差距很大,这方面只能是继续等待。
最后,自我纠正一下这个帖子的标题的含义。毕竟时过境迁,如今“慎用AJAX框架”的提法或许是有些不妥,我觉得我们可以从新的角度来看它:
1. 谨慎的选择AJAX框架。
2. 合理的认识、应用AJAX框架,要理解框架为我们做了什么,必要时可以脱离框架做自己的简单实现。
3. 关注AJAX框架的发展,得明确现在用该框架什么能实现、什么还不行、什么时候行。
re: 慎用AJAX框架 weidy 2006-10-18 17:25
@路过
一般的项目的话用DWR和DOJO来做应该没什么大问题,我刚刚在一个比较小项目用了,用dojo做RIA,处理JSON数据, DWR做远程调用,效果很好。
re: 慎用AJAX框架 weidy 2006-08-07 17:40
@domain
关于那个项目(实际上是个产品)具体的东西几句也说不清楚,有些涉及具体实现的也不能说太多。我倒是愿意就Bug分析和项目管理和大家讨论一下。实际上大公司的很多产品的代码写的是很弱智的(我上次参与的那个项目的代码就是由印度的软件工人写的),单看代码都非常一般,但是他们产品的质量却能得到保证,关键是项目过程组织的好, 尤其是测试的力度非常大,这个产品一般每个版本都要安排十几个人测上两个月,进行各项的测试,测试 -> qa开bug -> develop解bug -> qa再验证, 流程虽然不十很复杂,但贯彻的很好,很值得国内企业学习。 当然相应的成本也是很大的,那个产品的贵到了国内没有一家企业愿意买,现在基本就是国外一些大厂商用。
产品强大的功能怎么实现的?明确的业务需求 + 持续的开发完善。关于后续维护,按我的体会并没有太多的玄机,投入+简单的规则+执行,从一开始就是这样。看看现在,每天在论坛、Blog上各个软件公司大大小小LD都在大倒苦水,大谈软件项目管理的规定不能得到贯彻,似乎软件质量保证是个解不开的死结。其实说到底,是国内这些LD们不会真正舍得把钱把人投在质量保证上,总想走捷径,从开始就不花钱,不花钱又希望能开发出有好的产品,最后的结果就是天天空谈或者定些不伦不类的执行不下去的开发流程,到最后被迫花钱来换质量时,往往为时已晚。
这两篇文章我前几天都看过的,我也认为作者就是搞噱头,可笑的是居然用AJax的图书销量比Java多做论据,也不看看那些写Ajax的书里的例子有多少是在Java里实现的。在工业领域,像PHP这样几乎没有标准支持的语言会比Java强?这个问题几乎都不用回答。
re: 慎用AJAX框架 weidy 2005-12-01 16:55
的确,原来一无所有,现在有了轮子,将来肯定就会有车.... 大家要努力去造车,只不过决心造车之前要弄清楚这些轮子适合在什么地里跑。
如果按现在的趋势发展下去,灵活、稳定的AJAX框架应该是指日可待的,这要靠大家的努力,尤其是像 " 读书、思考、生活 " 这样热心AJAX技术的人。
re: 慎用AJAX框架 weidy 2005-11-29 22:38
首先感谢“读书、思考、生活”推荐的三本书,让他们看是不用了,我自己看看倒是不错,:)。不过你说的 用了5、6年AJAX开发的“高手”,却至今都没有总结出好的“模式”、“经验”云云, 就不太地道了,你怎么知道人家没有总结?不是这些走在前面的人,谁写《Ajax Design Patterns》、《Professional AJAX》这样的书给大家看?
其实我的写这篇blog的初衷是想告诉大家真正实现AJAX的框架有很大的难度,需要投入很多,如果想把项目设计成基于AJAX框架就要慎重。我并不是想过多讨论这个项目的本身的各种问题,我也没说过这个项目是完美的。
话说回来,我们这个的项目的AJAX框架(或者说准AJAX框架)现在已经能转的非常好了,Bug也早解完了。但是,为了让它像今天这样运行良好,企业投入是非常大的,开发维护的成本也都要大很多。我认为这就是它不成功的地方之一,如果少用一些AJAX这样东西,它就可以更快更好的达到目标。
实现完整的AJAX框架编写复杂、容易出错这个问题是非常明显的,不是说有高手就能避免的。退一万步说,假设你“读书、思考、生活”是绝顶高手,能搞定一切,你能保证你的Team里所有人都是高手么?
“设计水平不够,也不要把帐赖到AJAX这样的新技术头上” 这话说也不太妥: 首先AJAX不是什么新技术。 其次设计水平的提高和积累本来就是渐进的,就像最初的struts出来时,大家都说好,用两年,它的不好的地方大家又都清楚了,于是spring、webwork这样优于它的框架又被大家推崇。没有人能一次设计一个多完美的系统,我们的系统都是在不断的改进的过程中。
“如果你的项目只能用IE访问,那能算是遵循标准” 呵呵,的确这是俺没弄清楚了。但是可以想象要开发一个遵循标准的程序,实现各种复杂的功能,岂不要付出更多开发成本?
最后还是要多废话几句,用着这些大公司提供的硬件和软件,遵循着他们的标准做开发,却攻击他们没有高手是没有什么意义的。何况也没有人天生是高手,都是要从失败中摸索出来,或许开发这个项目UI端框架的人现在总结失败已经成了高手,能灵活合理的在项目运用AJAX了,很多人却还只是一味的为AJAX这个所谓新技术护短。
re: 某知名大企业的教训--慎用AJAX框架 weidy 2005-11-28 13:01
读书、思考、生活 说:
1、不遵循WEB标准的,算不得AJAX
2、bug满天飞,那就说明是水平不到家
3、加个新功能,JSP文件、标签、JS、后台类全要过一遍,
就说明系统设计有先天的缺陷
4、这大概可以说明,这个国外知名大公司里,没有一个数得上的AJAX高手
1、2.WEB标准是绝对遵循了的,bug满天飞的原因当然是多方面的,系统功能复杂必然会有大量的Bug,但过多的使用了AJAX这类技术导致Bug多确实是原因之一。大公司有人力物力去解这些defects,要实国内一般的企业很可能就因此陷入困境,这就是我担心的。
3. 系统设计有先天的缺陷,不可否认是有一点。系统开始做的那时候连Struts都还默默无闻呢,但是无论你如何进行设计,过多的使用AJAX去做展现必然导致系统的展现机制变得复杂。
4. 提醒"读书、思考、生活",可不要以为自己是高手,就不会犯别人犯过的错误。开发这套系统AJAX的人(可别以为我在其中哦,我只是有幸能看看他们的code)应该在web开发领域都是资深专家。想想在5、6年前没有AJAX概念的时候,就能开发出完整的基于AJAX框架来进行系统展现的人水平一定比现才开始深入学的人强吧。他们开发、完善了这么些年,至今还不能尽善尽美,这说明什么问题?
最后,我要说:我们当然可以克服和解决大部分问题,让它很正常的工作(就像这套系统一样),但是付出的代价可能很大。