锁定老帖子 主题:菜鸟也谈架构之C/S三层架构的轮回
该帖已经被评为隐藏帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-12-11
以flex为代表的富客户端还是挺强大的.
没必要非做成C/S |
|
返回顶楼 | |
发表时间:2009-12-11
最后修改:2009-12-11
用Java Web Start做项目的飘过
|
|
返回顶楼 | |
发表时间:2009-12-11
cs的 哎很久没做啦 很想很想他
|
|
返回顶楼 | |
发表时间:2009-12-11
cs 结构系统集成不是一般的麻烦,一个典型的应用人家要上portal你会怎么做,
我记得天津移动明确指出,不建议使用cs结构 你指出的两点弊端,我也不认可 引用 (1)实时响应速度差
(尽管已经做了集群、机器是小型机) 你说的响应速度差,是指http协议,冗余的地方多,还是指Tcp三次握手浪费 你使用google,使用百度,什么时候觉得慢 引用 (2)人机交互能力太弱,有些特殊的地方还不得不借助鸡勒技术ActiveX和Applet。使得B/S仅有的一点点部署方便的优势荡然无存。
为什么没有说flex和silverlight,更何况合理的使用ajax大部分人机交互的问题都能解决 |
|
返回顶楼 | |
发表时间:2009-12-11
最后修改:2009-12-11
JaNer 写道 菜鸟也谈架构
本人06年毕业 一直做JavaWeb应用的项目 大大小小做了5、6个吧 感觉B/S结构的应用 项目实施下来都不是很理想 虽然都验收了 但我觉得这些项目也顶多能给个百分制及格分 60分 主要弊端: (1)实时响应速度差 (尽管已经做了集群、机器是小型机) (2)人机交互能力太弱,有些特殊的地方还不得不借助鸡勒技术ActiveX和Applet。使得B/S仅有的一点点部署方便的优势荡然无存。 (尽管现在已经有很多RIA技术手段,比如EXT、Flex等~ 但都有各种问题。论证下来实施这些技术还是性价比不够理想。) 我的想法: C/S三层架构应该要轮回崛起了。 理论上说,B/S其实也是属于C/S三层架构的应用。但他的C这一层实在让人不爽。 扪心自问,你为什么要选择B/S来做行业应用系统(特质运行在专用网里的特定行业应用系统) (1)、为了跟时髦。觉得JavaEE(B/S)代表了时尚潮流,代表了先进。 扯淡。JavaEE并非就得把C做成浏览器应用。评价系统优劣最直接的三要素:方便、快捷、稳定(我一客户和我说话聊的,我决定很有道理) (2)、为了数据和业务逻辑集中,实现部署、升级的方便。 这恐怕是针对C/S原始2层架构而言.而且是因为你技术部到位不能做到完美的自动升级而把这一功能通过b/s模式变相解决吧。至于数据和业务逻辑的集中如果是C/S三层架构的话,B/S根本没有这一优势可言。C/S三成架构一样可以做到。 (3)、为了应用服务器集中、方便做集群和各种负载均衡。 C/S三层一样可以。 居然如此:我们为什么还要选择B/S 。 我的想法: 做一个c/s三层架构。总的方向还是基于Java。 方案一:用SWT/Jface和EclipseRCP技术做为UI层技术。实现一个纯粹的UI客户端。通过RPC调用JavaEE应用服务器发布的方法进行业务处理。此方案的问题:选择一种高性能且易于异构系统集成的RPC方法。(初定的方法是使用httpinvoker作为架构内部的RPC调用,并支持 webservice满足其他异构系统调用需求)不知道hprpse是否能同时兼顾高性能且易于异构系统集成? 方案二:用SWT/Jface和EclipseRCP技术做为UI层技术。实现一个纯粹的UI客户端。然后自己实现一个类似中间件或者应用服务器概念的东西,但不走http协议。考虑其他通信方式。我的业务逻辑组件也不希望再借助于Java应用服务器。而是直接将我的业务逻辑组件发布到这个中间件上作为服务提供给客户端调用。这只是偶的想法,不知具体怎么实现 不知道hprose是否能再这方面做点什么? 你的第二套方案不使用http,首先防火墙就是个问题,想使用别的通信方式,你招人估计3个月都招不到合适的 |
|
返回顶楼 | |
发表时间:2009-12-11
lz 的两个基于cs的方案挺不错的,我曾经也参与过类似的项目的,这里我补充一点!
1. 客户端使用 Eclipse rcp 2. 部署使用 java web start 来实现自动部署 3. client 和 server 通信可以选择一些跨平台跨语言的序列化或rpc框架,如 facebook 的 thrift,google 的 protocol buffer 以及 hadoop 的 avro,关于这些序列化框架的性能,google code 上有一个专门的项目做 benchmark,不妨到 google code 上搜一下 其实如果client 和 server 都使用 java 的话使用 java 本身的序列化以及网络功能来实现并不困难,效率也不错。 |
|
返回顶楼 | |
发表时间:2009-12-11
一句话:这个世界不是你说对了算,也不是我说了算,是用户说的算,用户看到B/S就痴迷了。
|
|
返回顶楼 | |
发表时间:2009-12-11
BS就是节约客户端。而且一升级,集体升级了。
使软件成为了一种服务, 用范伟的话说: 只要告诉我密码,我就能用。 不过从速度和灵活性上,跟cs差距太大了。 |
|
返回顶楼 | |
发表时间:2009-12-11
B\S的优势在于不用装客户端
|
|
返回顶楼 | |
发表时间:2009-12-11
这种想法我们也做过,我更倾向于基于消息的而不是基于RPC的。楼主说的不使用http协议真是让人无法理解。应该把服务端架构做好,客户端可以选择的技术很多,不同的应用可以选择不同的客户端技术,只有更适合的没有更好的。
|
|
返回顶楼 | |