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

最近在关注extjs4. 飞跃

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

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

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

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

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

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

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

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

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

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

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

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

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