[原创]总结三年使用Extjs开发One Page One Application的SSH架构经验

我已经实践互联网OPOA的SSH架构足足三年了，总结一下以下经验，欢迎各位讨论和拍砖：
优点：
1. 用单页面只加载一次Extjs类库，加载页面速度快，即使放互联网，部署产品阶段时，用GZIP压缩类库，把其他js统一打包，容量也不会很大，可以接受。
2. 提高开发效率1，我前端使用了3.0的Direct的js类库，后台使用网上找的Direct开源后台，js就可以直接访问后台service方法，action的代码量几乎等于0，业务都在service实现，request中的session对象通过在方法增加Map对象补充。
3. 提高开发效率2，在使用Direct技术的同时，编写service公共类用于继承，特别是实现查询的方法，在脚本上定义查询哪个Java对象，SQL条件等，使用Direct技术直接访问service的公共类方法，减少编写多个查询方法，如果更完善点，增删改都可以用这种方式实现，现阶段只实现的了grid的增删改。
4. 提高开发效率3，store的JsonReader不用手工写，在第一次加载Action的时候除了映射Service方法给前台Direct，还可以把需要的reader从java对象动态生成给前台。
4. 提高开发效率4，在开发阶段，使用动态加载脚本的方式调试脚本，如用Jsloader，为了避免修改脚本后浏览器缓存没有加载脚本，编写一个action转发到指定的脚本，action.do?id=XXXX(随机数)，强制每次访问脚本都重新加载，这样，我调试脚本就不用刷新页面，关了tab，重新打开即可加载最新脚本，通过动态加载脚本，就可轻易把功能界面分割成多个子脚本，通过主功能脚本动态调用和调试子脚本，非常方便。

缺点：
1. 开发人员培训周期长，根据具体开发人员的水平，快的二、三周左右，慢的三个月也有，这个时间是以整个架构熟悉包括前后台技术，能够单独实现一个功能模块计算。因此，对新的开发人员必须有一定的培训机制和培训环境，特别注意代码管理。
2. 代码维护困难，即使使用了编写子脚本的开发模式，维护复杂功能的代码还是非常头痛，所以代码管理和详细设计文档是必须的。
3. 开发太灵活，工作量翻倍增加。使用了Extjs以后，其实你B/S模式的开发已经非常接近C/S模式开发，每增加一个按钮、窗口、Tab或一些交互的功能，都会使你开发工作量翻倍增加，即使脚本开发经验丰富的我，也头痛不已，有时用jsp开发一两天实现的功能，你会花一个星期实现，当然实现了非常好看和实用，操作都一个界面完成，但你要考虑每增加一个小功能，因为交互性可能会影响其他功能，这样有很一部分时间就花在调试和完善代码的阶段。
4. IE浏览器的死穴。由于IE浏览器占用内存只增无减，我想尽办法也没能解决，如果你一个功能界面很庞大，再用多个Tab动态加载子脚本，除了操作响应感觉越来越慢外，如果一次性关闭多个Tab，就会提示“javascript运行慢，是否终止”，如果简单的功能界面，交互性不强，就不会有太大影响，所以要用Extjs做大系统，不能不考虑这方面，使用chome浏览器可以解决内存问题，但你能强制互联网上的用户用chome吗？现在我解决关闭Tab的问题，是通过加入延迟关闭机制，逐一关闭，但也不能100%解决，更解决不了IE内存不断膨胀的问题，最后用的慢了，让用户Reload页面吧。
5. 安全性。前台脚本实现了大部分操作功能，安全性就很成问题，不管你实用什么手段，脚本代码都是要暴露的，reader和后台方法就更暴露无疑了，也不是不可以解决，转换的时候改名吧，所以这都是影响Extjs开发的MS系统一直不能占据互联网市场的主要原因。

    现在我在考虑新的架构，其实也不是新了，就是使用Yahoo UI，简单看了一下，发现YUI对性能方面考虑更完善点，新架构将恢复以前开发jsp页面的模式，页面使用多少YUI控件就加载多少，减少界面交互功能的开发，按实际需要设计开发，不追求C/S模式的操作方便性了。

    以上是我见到大家讨论热烈，总结了之前几年的开发经验和挫折，欢迎大家讨论和拍砖。

评论

24 楼 atian25 2011-04-07  

KimHo 写道

racke 写道

IE下性能的问题可以考虑chromeframe
http://code.google.com/chrome/chromeframe/
可以在页面上提示用户安装，可以解决一部分问题，但毕竟选择权还是在用户。

象楼主这类application另可以考虑用gwt版的 gxt.
http://www.sencha.com/products/extgwt/
刚开始可能觉得开发速度不如js，但是随着开发的深入需求的变化，越来越能体会到java的好处。
js这样的语言很难做大型的设计。

GXT用的是后处理模式，性能不如js的，优点是方便调试而已。
js这样的语言很难做大型的设计？笑而不语

笑而不语,不知道GMAIL和WEBQQ是否算大

23 楼 mygol 2011-04-07  

chinafather 写道

楼上的哥们 ext目前还是太大，做ria可以用，而且界面风格统一不象jq的插件风格迥异，就是希望ext啥时候能真正实现小这个功能

ext4现在可以异步加载

22 楼 chinafather 2011-04-07  

楼上的哥们 ext目前还是太大，做ria可以用，而且界面风格统一不象jq的插件风格迥异，就是希望ext啥时候能真正实现小这个功能

21 楼 tianzhou0374 2011-04-07  

B/s的主要优点是：
1、无需安装客户端，如一套财务系统，做的好的话无论在谁的计算机上，无论在哪里只要输入网址就可以完成操作
2、无论是在iphone上还是在台式机或IBM工作站，以及国产LINUX（zf采购）中无需重写客户端。
3、通常HTTP协议无需特殊配置防火墙，通常超复杂的大公司的局域网或环境都无需写额外的配置。
4、同样很简单就可以做mashup.可以大幅度的融合网上现有资源，也可以很方便的做ROA式的开发。
5、在B/S中，尤其在OPOA中，可以根据不同的客户响应不同的代码，每次访问都返回最新的系统，bug等等也能最快的得到调整。


在ExtJs中，我建议尽量不要用iframe，或者核心不要用iframe来构架.放在长远看，用iframe会带来很多问题，尤其不同浏览器间的执行差异。

20 楼 KimHo 2011-04-06  

rocker96 写道

jjx 写道

其实这种结构同c/s分布式程序没有区别

但如果用delphi+dataabstract这样的分布式框架，或是windows forms+wcf ,开发效率提高的可不是几倍，而且现在c/s的程序更新分发用自动更新或是潜入语言，已经同b/s没有区别了，人类总是为形式所累

我以前也是delphi出身，其实B/S再怎么强开发效率都不如C/S吧，为什么搞B/S，推B/S，就是为了好忽悠老板呀，混口饭吃而已，extjs的控件设计模式很像delphi，学delphi的时候没学会写控件，所以现在用extjs写控件，呵呵。

BS架构的最大优点在于：部署和系统升级……

19 楼 rocker96 2011-04-06  

jjx 写道

其实这种结构同c/s分布式程序没有区别

但如果用delphi+dataabstract这样的分布式框架，或是windows forms+wcf ,开发效率提高的可不是几倍，而且现在c/s的程序更新分发用自动更新或是潜入语言，已经同b/s没有区别了，人类总是为形式所累

我以前也是delphi出身，其实B/S再怎么强开发效率都不如C/S吧，为什么搞B/S，推B/S，就是为了好忽悠老板呀，混口饭吃而已，extjs的控件设计模式很像delphi，学delphi的时候没学会写控件，所以现在用extjs写控件，呵呵。

18 楼 KimHo 2011-04-06  

racke 写道

IE下性能的问题可以考虑chromeframe
http://code.google.com/chrome/chromeframe/
可以在页面上提示用户安装，可以解决一部分问题，但毕竟选择权还是在用户。

象楼主这类application另可以考虑用gwt版的 gxt.
http://www.sencha.com/products/extgwt/
刚开始可能觉得开发速度不如js，但是随着开发的深入需求的变化，越来越能体会到java的好处。
js这样的语言很难做大型的设计。

GXT用的是后处理模式，性能不如js的，优点是方便调试而已。
js这样的语言很难做大型的设计？笑而不语

17 楼 jjx 2011-04-06  

其实这种结构同c/s分布式程序没有区别

但如果用delphi+dataabstract这样的分布式框架，或是windows forms+wcf ,开发效率提高的可不是几倍，而且现在c/s的程序更新分发用自动更新或是潜入语言，已经同b/s没有区别了，人类总是为形式所累

16 楼 racke 2011-04-06  

IE下性能的问题可以考虑chromeframe
http://code.google.com/chrome/chromeframe/
可以在页面上提示用户安装，可以解决一部分问题，但毕竟选择权还是在用户。

象楼主这类application另可以考虑用gwt版的 gxt.
http://www.sencha.com/products/extgwt/
刚开始可能觉得开发速度不如js，但是随着开发的深入需求的变化，越来越能体会到java的好处。
js这样的语言很难做大型的设计。

15 楼 yizhilong28 2011-04-06  

同感
Ext的学习成本确实有点高，Ext内部的一些机制设置，有时让人很抓狂
理解新手写的Ext代码，头疼。。。。

14 楼 rocker96 2011-04-06  

tianzhou0374 写道

OPOA可以用ExtCore+Extbase,大小gzip完我记得是几十K,然后用Ext4的动态加载。
OPOA登录时先用HTML给用户显示一个首页和输入用户名密码的地方，同时在后台加载ExtCore+Extbase那几十K的包，一般来说用户输入完成后基本上加载完毕。
多用305头效果会好一些，实在不行把JS都压缩后放在nginx上，速度也很快。

    ExtCore+Extbase的架构设计不错，只要完美解决ie内存问题，应该是Extjs将来的发展方向。
    其实不一定把框框限死在OPOA，我设计的架构也是支持iframe的，只是OPOA优点也很突出，所以几乎没怎么用iframe.

13 楼 rocker96 2011-04-06  

skzr.org 写道

希望楼主一直走下去，这样可以让投资得到持续的回报。
重新学习yui，你会一样的面临各种问题的，这个时候还是会重复走以前的路——yui看来也有问题，最后我们还是自己开发一套，结果几年后发现自己做出来的和当时的yui差不多，而且还有一堆遗留的设计和bug需要维护。

老实说，extjs很好很强大，如果做ria最终它们的ui设计（component、layout、等等）都是一样的。

现在自己也是选择了ExtJS做东西，把所有的东西封装为组件。
回报还是很不错的，降低了重复劳动。现在想在哪儿用就可以用。结构也清晰了。

    主要是因为工作关系，所以开始接触YUI，也不想放弃Extjs，但三年了，一个人走Extjs的路，挺孤单的，如果多一两个人一起研究和进步，估计也就一年不到就可以做的很好，像二楼的意见。

    当然，一个系统架构不能只考虑前端展现，后台的业务逻辑处理和开发效率也是重要考虑之一，extjs再强大，没有像Direct的后台支援，也就是一个漂亮的花瓶，所以前后台的结构设计，降低重复劳动，都要认真考虑。

    回报已经不错了，起码提高了对架构的设计理念和团队开发的建设，这都是宝贵的经验。

12 楼 tianzhou0374 2011-04-06  

OPOA可以用ExtCore+Extbase,大小gzip完我记得是几十K,然后用Ext4的动态加载。
OPOA登录时先用HTML给用户显示一个首页和输入用户名密码的地方，同时在后台加载ExtCore+Extbase那几十K的包，一般来说用户输入完成后基本上加载完毕。
多用305头效果会好一些，实在不行把JS都压缩后放在nginx上，速度也很快。

11 楼 clue 2011-04-06  

EldonReturn 写道

> 我们基本上已经解决了IE的内存释放问题，过程很痛苦，很难表述清楚。
> 各主要页面的数据刷新、打开再关闭，已无Dom节点泄漏，内存基本无增长

定义一个_Widget父类，里面设个destroy，然widget在被主动销毁的时候释放全部资源。是这么做的么？

Ext本身就有考虑资源释放，只是做得不太完善罢了。

资源未释放的根源是对象仍有可访问的引用及JS <-> Dom循环引用。
自3.1以后，JS <-> Dom的循环引用基本已经没有了，每个组件调用destroy时都会将它创建的Dom节点一并销毁。

我们主要做的就是找出导致资源未释放的引用，然后在销毁方法中改进它。

例如Panel在未render时就销毁，未一并销毁它所创建的tbar组件。而Ext中所有组件(Component)都在Ext.ComponentMgr中注册，导致tbar组件不会被释放。

再例如，Function#createInterceptor方法，会将原方法及最近一次调用的scope存于注入函数上（fcn.target = me;fcn.method = method;），如果有某个组件扩展方法用到了它，那么这个方法会缓存最后一次调用的组件，导致它因引用而未释放。

当然，除以上两种外，IE还有特例的，好像IE8及以前版本，都无法释放form节点。而IE8中甚至A, IMG, INPUT等节点都是创建后就无法释放（用sIEve验证）
（参考：Memory Leaks in IE8）

对于OPOA来说，这些引用导致的未释放会很严重，因为组件间的引用会把它们交织在一起，一旦一处没处理好，一大片组件即使已经destroy但JS对象仍因引用而继续保留，积少成多最终不可收抬。

另，以前发过一篇总结，可以参考下： http://clue.iteye.com/blog/704883

10 楼 atian25 2011-04-06  

最近在关注extjs4. 飞跃

9 楼 skzr.org 2011-04-06  

希望楼主一直走下去，这样可以让投资得到持续的回报。
重新学习yui，你会一样的面临各种问题的，这个时候还是会重复走以前的路——yui看来也有问题，最后我们还是自己开发一套，结果几年后发现自己做出来的和当时的yui差不多，而且还有一堆遗留的设计和bug需要维护。

老实说，extjs很好很强大，如果做ria最终它们的ui设计（component、layout、等等）都是一样的。

现在自己也是选择了ExtJS做东西，把所有的东西封装为组件。
回报还是很不错的，降低了重复劳动。现在想在哪儿用就可以用。结构也清晰了。

8 楼 chinafather 2011-04-06  

ext 采用gzip压缩后大约200多k的大小，如果采用单页面可能整个页面是会有些大，目前ext4是提出了动态加载，不过目前为止还是没见到真正实现；局域网可以考虑用ext的，但是对于门户或者网站类型的似乎还没到时候

7 楼 KimHo 2011-04-05  

one page one application，其实是个ajax框架都能做到的了，只不过extjs提供了更多功能更强的组件罢了。
性能其实是个大问题，这个貌似还没太多解决方案，基本依赖于extjs的内存控制设计了。

6 楼 bugu1986 2011-04-05  

我们采用的是one module one page，效果好一些，因为实际上我们的项目不是很大。

没有采用动态加载，可能还没多到你们的那个级别。

我也是用的一个类一个文件，而且基本是扩展了Ext的组件用，这样把好组件的关，代码质量会高一点。

5 楼 archerzz 2011-04-05  

我觉得缺点中3 4和你是one page app有关，因为是one page，不容易实现界面逻辑分割，自然复杂度上升，容易出现问题。
缺点5和客户端没有关系，服务端必须要校验，否则你用JSP也是会被攻破的。