请教单页系统的技术选型

大东哥 发布于 2011/08/29 11:30
阅读 764
收藏 0

计划做一个是类似webqq那样的单页系统(别误会,不是要做个像qq那样的IM),前端展示会更复杂,个性定制更强,并且是放到外网上。

项目特点,前端大量动态展示,单页web系统,大量ajax交互,dom交互,服务器端推送,状态维护。

初步框架选型:

jsf+seam+hibernate,推送部分没做过,还在考虑。

    理由:jsf+seam,状态的维护比较容易,ajax交互代码相对容易控制,自定义组件方便,conversation范围也很合适这类应用,richfaces或icefaces似乎支持推送。

    缺点:jsf对前端的dom展示和操作,灵活性欠佳,页面的大小不好控制。服务器端会维护大量状态,服务器负担较重,jsf的ajax请求包大小难控制,效率没手写ajax高,可能会影响并发效率,集群环境也不友好。(seam的conversation可是用session保存状态的)。

2.js+spring+hibernate。

   理由:前端dom展示会比较灵活,可控性强,页面可优化程度高,对ajax的请求服务器端负担相对低,server不保存状态,集群友好。

   缺点:js代码复杂,维护相对困难,由js保存状态,很可能陷入状态维护泥潭。js代码还是比java代码容易失控。

3.综合1+2

4.无框架。

如果确定状态由js维护,那怎个开发的精力就得在js上,服务器端代码相对简单。由server服务状态,整个服务端架构就不一样。

问题在于,状态由哪端保存嗫,亦或者平分伤害(平分伤害可能是最麻烦了,两头都得顾到呀)。

关于推送,是怎么做的呢,查过有websocket,轮循,还有点什么方法?

加载中
1
qycms_cn
qycms_cn
flex(as3.0) + java足够。
张金富
张金富
同感!
0
zstacks
zstacks
若是独立项目未必非得固定在JAVA平台,WEBSocket有IE在,选择有点痛苦。WEB IM其实可以考虑下Node.js  http://chat.nodejs.org/(我部署了个简单测试,挺方便的) 
0
大东哥
大东哥

引用来自“Rushmore”的答案

若是独立项目未必非得固定在JAVA平台,WEBSocket有IE在,选择有点痛苦。WEB IM其实可以考虑下Node.js  http://chat.nodejs.org/(我部署了个简单测试,挺方便的) 

主要是java是最熟悉的,其他可能虽然好,但不敢冒用,得仔细考虑。

感谢你给的node.js参考,看了下,在ie下不好使啊。

其实还可以用flash,但是考虑到现在不基于html+js的话,假若过渡到html5,前期开发投入的都白费了。

这个项目关键就在于前端,其实类似webos了,只不过没这么强,dom交互和状态维护都麻烦。

心理到是有点底了,jsf可以定义renderer,可以根据不同的client用不同的rendered。

大东哥
大东哥
@张金富 : 另外,jsf的renderer是可以根据Agent动态切换的,也就是可以同时存在html4,html5的renderer,不需要推倒原来的设计。
大东哥
大东哥
至少比flash -> html容易吧,当然可能我这么想,也有过渡设计之嫌。
张金富
张金富
html4改为html5的话,也是需要推倒重来吧?
0
zstacks
zstacks

这种项目将以你不要用jsf,jsf明显过重了,脚本生成部分不如不用框架来控制,我们有团队使用jsf,最后都在前端控制部分头疼,以至于最后都感慨:JAVA里面框架是浮云,OSC其实挺值得借鉴学习的是红薯轻量级的应用了JAVA的成熟,砍了Hibernate,使用Apache Commons, 砍了Struts自己做了个简化版熟悉的MVC。在Python下,则可以做到更轻量级处理,比如FAWS3(http://www.fapws.org/),基于epoll事件模型,自己简化定制后QPS可以到1.2W,Tomcat7的helloworld在6k左右,当然成熟度就靠自己来掌握了,不过出了问题也是非常清楚的,毕竟是自己的整的

0
大东哥
大东哥
我第4点说的,无框架也在考虑范围,我得自己多做几个简单的demo试试。
返回顶部
顶部