|
锁定老帖子 主题：菜鸟也谈架构之C/S三层架构的轮回
该帖已经被评为隐藏帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-12-11
真TM扯，连为什么BS会替换CS都没搞明白。
CS需要安装客户端及客户端的版本更新是个大问题。 隐掉吧！！！ |
| 返回顶楼 | |
|
发表时间：2009-12-11
最后修改：2009-12-11
lvgang 写道 如 facebook 的 thrift，google 的 protocol buffer 以及 hadoop 的 avro，关于这些序列化框架的性能，google code 上有一个专门的项目做 benchmark，不妨到 google code 上搜一下
thrift-protobuf-compare http://code.google.com/p/thrift-protobuf-compare/ Serialization Time: |xstream%20(stax)|scala|xstream%20(xpp%20with%20conv)|java|JsonMarshaller|binaryxml/FI|xstream%20(stax%20with%20conv)|java%20(externalizable)|stax/woodstox|javolution%20xmlformat|kryo-optimized|kryo|stax/aalto|thrift|sbinary|protobuf|json%20(jackson)|avro-generic|avro-specific&lklk&chdlp=t&chco=660000|660033|660066|660099|6600CC|6600FF|663300|663333|663366|663399|6633CC|6633FF|666600|666633|666666&cht=bhg&chbh=10&chxt=y&nonsense=aaa.png)
Deserialization Time: |xstream%20(xpp)|java|hessian|xstream%20(xpp%20with%20conv)|JsonMarshaller|xstream%20(stax%20with%20conv)|java%20(externalizable)|binaryxml/FI|javolution%20xmlformat|stax/woodstox|stax/aalto|json%20(jackson)|thrift|avro-generic|kryo-optimized|kryo|sbinary|protobuf|avro-specific&lklk&chdlp=t&chco=660000|660033|660066|660099|6600CC|6600FF|663300|663333|663366|663399|6633CC|6633FF|666600|666633|666666&cht=bhg&chbh=10&chxt=y&nonsense=aaa.png)
Serialization Size: |xstream%20(xpp)|hessian|stax/woodstox|stax/aalto|javolution%20xmlformat|xstream%20(stax%20with%20conv)|java%20(externalizable)|json%20(jackson)|xstream%20(xpp%20with%20conv)|thrift|JsonMarshaller|binaryxml/FI|sbinary|kryo|protobuf|kryo-optimized|avro-specific|avro-generic&lklk&chdlp=t&chco=660000|660033|660066|660099|6600CC|6600FF|663300|663333|663366|663399|6633CC|6633FF|666600|666633|666666&cht=bhg&chbh=10&chxt=y&nonsense=aaa.png)
andot 写道 你最后说的两个方案都是 hprose 目前和将来要解决的问题。
有没有hprose VS. avro的比较结果？ |
| 返回顶楼 | |
|
发表时间：2009-12-11
各有千秋,但总体来说,c/s的优势还没没有b/s多
Flex,Sliverlight 不都在吗 |
| 返回顶楼 | |
|
发表时间：2009-12-11
html http
这些标准那么容易变？ |
| 返回顶楼 | |
|
发表时间：2009-12-11
我觉得你的想法，很有问题，C/S优势，但B/S也有很大的优势
就拿，我实施过的kingdee EAS HR来说，就是一个B/S和c/S结合的项目 但实施下来，我个人感觉，用户更愿意用B/S的系统，因为c/s要安装一个客户端，虽然在三层架构的c/s 系统中业务逻辑的运算可以在中间层完成，但客户端的界面渲染，就要耗费很大客户机资源，就拿kingdee 的EAS客户端来说，差点的机器根本别想用，还谈什么处理业务了 另外，现在b/s RIA客户端的技术也很多，并且在不断成熟中，不然为什么google公司的操作系统要考虑在 chrome中操作，而核心在云端了？ 这是一种趋势，其实个人的想法是，以后其实根本就不分什么b/s系统和c/s系统，Browser本身就是一个 功能强大的系统平台，随着web2.0,html5.0标准等的出现，这样的理想是可以实现的。不然google，oracle 也不会把自己的应用帮到浏览器上。 |
| 返回顶楼 | |
|
发表时间：2009-12-11
snailq 写道 我觉得你的想法，很有问题，C/S优势，但B/S也有很大的优势
就拿，我实施过的kingdee EAS HR来说，就是一个B/S和c/S结合的项目 但实施下来，我个人感觉，用户更愿意用B/S的系统，因为c/s要安装一个客户端，虽然在三层架构的c/s 系统中业务逻辑的运算可以在中间层完成，但客户端的界面渲染，就要耗费很大客户机资源，就拿kingdee 的EAS客户端来说，差点的机器根本别想用，还谈什么处理业务了 另外，现在b/s RIA客户端的技术也很多，并且在不断成熟中，不然为什么google公司的操作系统要考虑在 chrome中操作，而核心在云端了？ 这是一种趋势，其实个人的想法是，以后其实根本就不分什么b/s系统和c/s系统，Browser本身就是一个 功能强大的系统平台，随着web2.0,html5.0标准等的出现，这样的理想是可以实现的。不然google，oracle 也不会把自己的应用帮到浏览器上。 说得在理 |
| 返回顶楼 | |
|
发表时间：2009-12-11
方案二比较困难吧，自己实现中间件，成本会大很多的。
|
| 返回顶楼 | |
|
发表时间：2009-12-11
这个要看项目了
有些界面要求高，操作复杂的用B/S是很鸡肋，见过一个页面附加了几十个JS文件的代码，浏览器一跑起来速度不敢恭维。除非浏览器要做得更牛逼一点，HTML5.0早点来吧 |
| 返回顶楼 | |
|
发表时间：2009-12-11
最后修改：2009-12-11
downpour 写道 选择B/S架构可能更多考虑到的是集中服务的模式。毕竟一台一台机器去安装客户端，实施起来不是特别方便。
关于部署： EclipseRCP客户端可以考虑使用java webstart进行部署。即使不使用webstart也能够制作成安装包由用户下载自己完成安装。 而B/S应用的部署现状是什么？ 虽然理论上B/S是零部署的。但事实是什么样的呢？客户端机器大部分也用于上网，客户安装了各种各样的浏览器插件。如果你的系统对客户端的人机交互要求很高或者你的系统需要和硬件交互则你可能还需要使用OCX技术和applet技术。如果你使用了这种鸡勒技术的话那部署起来将会变得极其苦不堪言。即便你进行了数字签名，理论上OCX控件能够自动下载到客户端，但由于客户端浏览器环境千差万别，零部署将变成亲自上门部署设置部署不上的尴尬局面。最后干脆重做系统。 |
| 返回顶楼 | |
|
发表时间：2009-12-11
嫌界面难用就好好学习ajax和flex吧。
|
| 返回顶楼 | |
