[原创]总结三年使用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模式的操作方便性了。

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

评论

4 楼 changtiger 2011-04-05  

我做的是ERP系统，其中两个子系统使用EXT技术，感觉效果还是不错的。

3 楼 tsoukw 2011-04-05  

轻服务端是趋势，至于客户端，并不一定是要One Page One Application,毕竟面临的内存问题，以及复杂的组件架构所带来的性能要求都是不可避免的

2 楼 EldonReturn 2011-04-04  

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

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

1 楼 clue 2011-04-02  

个人总结能力不强，所以就以近2年来前端ExtJs OPOA开发经验补充一些个人看法吧

引用

1. 用单页面只加载一次Extjs类库，加载页面速度快，即使放互联网，部署产品阶段时，用GZIP压缩类库，把其他js统一打包，容量也不会很大，可以接受。

我们只将对ExtJs做的扩展及主要逻辑合并，其它文件全部代码压缩，动态计算依赖进行加载，PHP合并GZIP传输。
偶尔页面过于复杂时会慢一点，但也在几秒以内。

引用

2. 提高开发效率1，我前端使用了3.0的Direct的js类库，后台使用网上找的Direct开源后台，js就可以直接访问后台service方法，action的代码量几乎等于0，业务都在service实现，request中的session对象通过在方法增加Map对象补充。
3. 提高开发效率2，在使用Direct技术的同时，编写service公共类用于继承，特别是实现查询的方法，在脚本上定义查询哪个Java对象，SQL条件等，使用Direct技术直接访问service的公共类方法，减少编写多个查询方法，如果更完善点，增删改都可以用这种方式实现，现阶段只实现的了grid的增删改。

没有用Direct，但效果也类似，后端再也不用考虑html、js之类的东西了，纯JSON交互。
这样使得后端开发工作量很小

----------------------------

引用

1. 开发人员培训周期长，根据具体开发人员的水平，快的二、三周左右，慢的三个月也有，这个时间是以整个架构熟悉包括前后台技术，能够单独实现一个功能模块计算。因此，对新的开发人员必须有一定的培训机制和培训环境，特别注意代码管理。

赞同，基本上要熟悉JS语法、ExtJs，再加上已有的代码结构与接口等等，比传统网页开发要求更高
（普通网页开发门槛真的很低，很容易就上手，很多人都是以此入门的吧~?）

引用

2. 代码维护困难，即使使用了编写子脚本的开发模式，维护复杂功能的代码还是非常头痛，所以代码管理和详细设计文档是必须的。

JS的灵活性导致很容易出现难以维护的代码，个人更偏向于适当调整重构，设计文档啥的。。。很容易失去维护

引用

3. 开发太灵活，工作量翻倍增加。使用了Extjs以后，其实你B/S模式的开发已经非常接近C/S模式开发，每增加一个按钮、窗口、Tab或一些交互的功能，都会使你开发工作量翻倍增加，即使脚本开发经验丰富的我，也头痛不已，有时用jsp开发一两天实现的功能，你会花一个星期实现，当然实现了非常好看和实用，操作都一个界面完成，但你要考虑每增加一个小功能，因为交互性可能会影响其他功能，这样有很一部分时间就花在调试和完善代码的阶段。

OPOA下，界面上可供操作的东西多了，自然工作量也会大。有时还要考虑互相之间的影响。不过相应，界面的可操作性也更丰富。

引用

4. IE浏览器的死穴。由于IE浏览器占用内存只增无减，我想尽办法也没能解决，如果你一个功能界面很庞大，再用多个Tab动态加载子脚本，除了操作响应感觉越来越慢外，如果一次性关闭多个Tab，就会提示“javascript运行慢，是否终止”，如果简单的功能界面，交互性不强，就不会有太大影响，所以要用Extjs做大系统，不能不考虑这方面，使用chome浏览器可以解决内存问题，但你能强制互联网上的用户用chome吗？现在我解决关闭Tab的问题，是通过加入延迟关闭机制，逐一关闭，但也不能100%解决，更解决不了IE内存不断膨胀的问题，最后用的慢了，让用户Reload页面吧。

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

引用

5. 安全性。前台脚本实现了大部分操作功能，安全性就很成问题，不管你实用什么手段，脚本代码都是要暴露的，reader和后台方法就更暴露无疑了，也不是不可以解决，转换的时候改名吧，所以这都是影响Extjs开发的MS系统一直不能占据互联网市场的主要原因。

我们前后端分层很明显，只通过约定的JSON格式交互，后端基本都会做安全检查，前端的检查只是为了易用性，所以基本不存在安全问题。

-------------------------------

总的来说，目前的RIA开发还是令人满意的，优势很明显，至少在后期维护方面。
基本上是要一路走到底

我觉得我们和LZ最大的区别是组件化方面，各个文件都对应唯一的“类”，页面也是一个类，甚至通用的操作模式也是一个类。
这样使得最终产品复用度很高，逻辑也一直比较清晰，后续开发维护工作还是比较轻松的。