论坛首页 Web前端技术论坛

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

浏览 31522 次
精华帖 (0) :: 良好帖 (2) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2011-04-02   最后修改:2011-04-02
我已经实践互联网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模式的操作方便性了。

    以上是我见到大家讨论热烈,总结了之前几年的开发经验和挫折,欢迎大家讨论和拍砖。
   发表时间: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最大的区别是组件化方面,各个文件都对应唯一的“类”,页面也是一个类,甚至通用的操作模式也是一个类。
这样使得最终产品复用度很高,逻辑也一直比较清晰,后续开发维护工作还是比较轻松的。
0 请登录后投票
   发表时间:2011-04-04  
> 我们基本上已经解决了IE的内存释放问题,过程很痛苦,很难表述清楚。
> 各主要页面的数据刷新、打开再关闭,已无Dom节点泄漏,内存基本无增长

定义一个_Widget父类,里面设个destroy,然widget在被主动销毁的时候释放全部资源。是这么做的么?
0 请登录后投票
   发表时间:2011-04-05  
轻服务端是趋势,至于客户端,并不一定是要One Page One Application,毕竟面临的内存问题,以及复杂的组件架构所带来的性能要求都是不可避免的
0 请登录后投票
   发表时间:2011-04-05  
我做的是ERP系统,其中两个子系统使用EXT技术,感觉效果还是不错的。
0 请登录后投票
   发表时间:2011-04-05  
我觉得缺点中3 4和你是one page app有关,因为是one page,不容易实现界面逻辑分割,自然复杂度上升,容易出现问题。
缺点5和客户端没有关系,服务端必须要校验,否则你用JSP也是会被攻破的。
0 请登录后投票
   发表时间:2011-04-05  
我们采用的是one module one page,效果好一些,因为实际上我们的项目不是很大。

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

我也是用的一个类一个文件,而且基本是扩展了Ext的组件用,这样把好组件的关,代码质量会高一点。
0 请登录后投票
   发表时间:2011-04-05  
one page one application,其实是个ajax框架都能做到的了,只不过extjs提供了更多功能更强的组件罢了。
性能其实是个大问题,这个貌似还没太多解决方案,基本依赖于extjs的内存控制设计了。
0 请登录后投票
   发表时间:2011-04-06  
ext 采用gzip压缩后大约200多k的大小,如果采用单页面可能整个页面是会有些大,目前ext4是提出了动态加载,不过目前为止还是没见到真正实现;局域网可以考虑用ext的,但是对于门户或者网站类型的似乎还没到时候
0 请登录后投票
   发表时间:2011-04-06  
希望楼主一直走下去,这样可以让投资得到持续的回报。
重新学习yui,你会一样的面临各种问题的,这个时候还是会重复走以前的路——yui看来也有问题,最后我们还是自己开发一套,结果几年后发现自己做出来的和当时的yui差不多,而且还有一堆遗留的设计和bug需要维护。

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

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

0 请登录后投票
论坛首页 Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics