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

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