EXTJS与后台(J2EE)实战开发经验与心得总结。

如果能够在敝人博客贴上别人的美文,那是最好不过了,起码可以沾沾光。呵呵,下面这篇文章就是美文中的“美文”,很好的介绍Ext与J2EE的开发经验,对J2EE的开发人员学习怎么与Ext结合很有好处。原本发在JS堂的,文笔不错,现在有朋友需要瞧瞧,加上都是真知灼见,,既然这样,就转过来吧~~掠人之美出于礼貌也要说说为好。

EXTJS与后台(J2EE)实战开发经验与心得总结。

作者:andy_ghg

出处:JS堂

开发EXTJS一年半了,一边做Java一边做Extjs。我也在EXTJS官方的国际化资源文件中提过一个修正版的中文资源包,现在在最新的3.1.0版本中的国际化资源文件就是我去年提的那一版修正版。
我在项目中积累了不少失败的经验和心得,我们单位在国内应该是第一批使用Extjs开发大项目的公司吧,大约两年前就开始准备了。
那么,我就我在开发Extjs中遇到的一些困难、问题以及前后台搭配的一些冲突上做一个简短的介绍吧。

1.前期不够投入
这个怎么说呢?在前期调研的时候没有引起足够的重视,总以为Extjs嘛,无非就那么点控件,那么点东西。new一个window我能使就行了。需要一个grid 我就加一个gri d。结果导致代码运行效率的极度低下,变量名没有好的管理。采用过程式的编程,而不是OO思想。这个是最大的败笔,此问题至今没有被解决(我进去上班的时候他们已经编写了N行代码了,重构是不现实的了。)。目前还有很多公司依然偏执的认为,EXTJS就是JavaScript 嘛,在牛也是JS。最后,出现问题之后,就开始说:“Extjs效率太慢,无法容忍。根本不适合开发大型项目。”

2.对API的不了解,以及资料匮乏。
这个直接导致了N多无用的代码,说出来不怕大家笑,我曾见过ComboBox不使用displayField和hidden Field 来获取value和rawValue,反而是自己在哪里写了N多行代码来获取这两个值。(不过大家也要认识到,当时做EXTJS的国内很少很少,能写出 来,也算不错了。)那么,这种偏执,导致了自己的代码经常性的报错,不可预料的一些错误。焦头烂额之中忽然看到百度或者Google 上有这方面的资料。恍然大悟。后来网上资料慢慢多了,又出现新问题了,那就是下面要说到的问题。

3.不相信自己的能力,过度依赖百度和Google
我刚进单位的时候,我写一个继承(ext end)。 都要问:“这是什么写法?我没见过呀。百度Google上没见过呀,这样写能行吗?”。这个思想的产生,不是因为别的,而是因为在开发初期不重视 EXTJS,偏执的埋头写自己的代码造成了很多损失之后,开始产生了不自信。从而当出现问题之后,没有自己去反思为什么会出现问题,焦头烂额之后就直接去 开帖子问别人,百度一下,Google一下。不优先考虑API和它的源码。这导致自己的不自信。认为,如果从百度上抄来的代码不能运行,那是别人的错而不 是自己的错。别人写的代码自己在百度或者Google上没见过,就认为不行。三思而后行。

4.前台与后台的那些纠纷
大家知道,Extjs中很多数据要显示出来,必须要有一个字段对应后台的数据,例如grid中的columnmodel,我前台有id,后台也要传送一个 id字段我才能显示数据。但是在实际开发中,出现问题了。后台建库建表的时候,从未征求过表示层的意见,也是近似偏执的认为,建库建表与表示层没关系,到 时候处理一下塞到前台让他们显示就得了。这下苦了表示层了,一条数据上来,字段与前台不对应,怎么办?比如,前台一个grid中的字段显示的是年月日,而 在数据库 中 年月日是三个字段(只是打个比方),那么我就要在Action做字段拼接,而这个步骤,应该是在数据查询上来的时候就拼接好的(实际应该在业务逻辑层做这 个事情)。结果导致了什么?Action当中充斥了大量的StringBuilder和循环,搞得Action中杂乱无章。好不容易发现来了一条比较顺手 的数据,只要JSON-lib转换一下就搞定,可惜,里面居然有length之类的敏感字段。苦闷。为了多个表的数据兼容(例如A表和B表要同时显示在一 个Grid里面,A表B表字段不一致),更是写了无数的逻辑处理。当然,我这里描述的可能有点问题,实际开发中的困难真的是只可意会不可言传……

5.页面逻辑与后台逻辑分不清
打个最简单的比方,我需要截取时间,来将某个视频截取出一段用于播放,这个逻辑应该在什么地方做?页面吗?我想不应该吧,JavaScript可以做时间 运算,但是这个运算最终要把运算结果传递到后台,再由后台将切割好的视频流发送到前台,为何我们不能在后台完成这个逻辑?JavaScript毕竟不擅长 来处理逻辑。一旦遇到异常,JS总是要花跟多的时间去处理这个异常,相反,Java是很擅长做这件事情的。

6.JS的调试
还是那句话,由于前期(在我进入公司之前)不重视表示层,并且由于各种原因。有些东西不能在火狐上跑,就抛弃了火狐,认为我们的东西只要运行在IE上就行 了,写了一堆不兼容火狐的代码。这下惨了,亲爱的火狐以及Firebug离我而去,调试成了我们每天茶余饭后必谈的话题。最后我找了个折中的方 法,CommonJS插件来调试,可是由于种种原因,在IE6上运行的效果不理想。于是我不得不使用log4JavaScript在哪里死磕。浪费了时 间。浪费了精力。

下面,我就我所遇到的一些问题提出一点开发上的建议
1.保证自己代码的命名规范,JS中的注释一个都不能少,Java通过Eclipse能定位到变量所在的文件,JS你Control健按死了也定位不过去(Spket 只能定位到声明,不能定位到文件)
2.保证自己所写的模块能个单独运行、测试。模块与模块直接不应当耦合过于紧密。过度的耦合你会发现,当我要替换某个模块的时候显得相当的困难。
3.在讨论数据库、后台、整体流程的时候,表示层一定要竖起耳朵来听,不要到时候因为数据库少了一个字段来在Action做表连接查询。
4.要让别人知道,JS其实不像他们想象的那么简单。
5.多看API,多看源码,少上Google和百度。坚决不拷贝网上现有的例子作为己用。
6.出了问题先查原因,多写笔记。错误肯定不会只出现一次。
7.打理好自己的JS文件,动一个西一个,名字词不达意你会痛苦的。
8.你不是一个人在战斗,你不是在以学习的心态来写EXTJS,你现在是在用它来创造价值。一个人的力量是薄弱的。



我个人感觉Struts1与Extjs配合的其实不是很尽如人意的。相比较来说,Struts2要好一些(实际上Struts已经没有存在的必要 了,Servlet或者SpringMVC也能很好的解决需求。)。JSON-Lib的版本,我觉得Struts2目前自带的版本过低,有机会最好替换成 最新版的JsonLib。还有就是,前台如果没有特殊的需求,就用HTML页面吧,JSP也是要编译的,首次运行比较慢,而我们做开发,几乎都是首次运 行。这样能减少不少时间。
能省掉的代码尽量省掉,过多的代码只会造成你的bug增加,没有任何好处。

敢于怀疑,很多时候(特别2.0)。有些BUG是由于EXTJS自身带来的,而不是因为你代码写的有问题,所以,看清楚究竟是哪里出了问题,对你来说能把握住问题的关键。

Extjs是基于JavaScript的,也许你觉得你根本不会JS也能写出一个window,觉得这样就可以了。但是你错了,如果对AJAX没有一个深 入的了解,你永远都只停留在会写,而不会上升到怎么去写的更好这个层次上来。如果你仅仅是为了逃避繁琐的CSS、DOM和JavaScript而使用 EXTJS,我劝你最好还是花时间去了解一下。我不会害你的,放心。

不要偏执,如果看这篇文章的过客是一个准备用EXTJS来开发的调研者(经理大人或者主管大人),希望您能有足够的重视,EXTJS写的不好,会让您大失所望。必要的精力和资金投入,是必须的。并且请在开发周期上稍微长一点。

Extjs就像EJB,未来的路怎么样,自己琢磨。存在即是理由,说EJB烂的,EJB依然在很多地方被应用。说EXTJS不适合大型项目的,试了才有发言权。轻量级与重量级的孰优孰劣,自己考虑吧。


也希望高手达人能分享自己的心得与经验,让我从中受益。不过本帖不欢迎抬杠的人跟帖,讨论问题而已,好自为之。客观评价。
谢谢。

©️2020 CSDN 皮肤主题: 岁月 设计师:pinMode 返回首页