世上没有B/S系统,只有B系统和S系统.

先说些与标题貌似无关的话.

随着prototype DWR 等ajax框架的流行,
服务器端生成js代码返回客户端,由客户端调用(直接调用或eval)似乎已经成为了一种很正常的做法(是否流行我不知道).

这种做法(其实是一种设计)本身无可厚非,但是常常被人错误的理解和应用
(此处所谓的"错误"是基于我的立场,也许更多的人会认为我的观点才是错的 呵呵).


用过DWR的人都知道,实际上DWR传给客户端的JS并不是包含了很复杂的业务逻辑和表现逻辑,他只不过是向客户端发送了一些信息,
这些信息告诉了客户端如何调用服务端暴露出的服务.这些信息本质上只是一些数据,确切的说只是一些参数.
DWR实现的web remoting,只是对下面这种做法的一个变种.

ajax.request("service对应的url","service需要的参数","service调用结束后要做的事情")

DWR传过来的JS,实际上的只是扮演着"service对应的url","service需要的参数","service调用结束后要做的事情"这些参数所扮演的角色.
对于真正的业务逻辑还是包含在服务端的service里.

所以我不止一次的说过"没什么事情是必须要用DWR那种方式来做,而用prototype + servlet做不了或是做起来很困难的".
因为两者都能够做到而且也都正做着同样的事情.


但是DWR的这种做法有时候会产生一些不良暗示:服务端生成js供客户端调用是一件很不错的事.
甚至容易让人把这种做法和JSF的事件机制混为一谈.
于是通过ajax请求返回的信息变得丰富多彩.其中最可怕的就是返回复杂的HTML和JS脚本.

现在还有一种可怕的事情是 客户端提交js脚本,服务端用rhnio运行
(我曾就就做过这种可怕的事 呵呵,但是那个系统尤其客观性,不过其实完全可以避免的,只是当时懒了).


在一个ajax的请求与响应中,服务端与客户端交互的信息应该只是作为数据载体的字符串(xml json序列等).
这些数据会告诉对方要去做什么 以及为对方提供必要的参数,而不应该包含告诉对方怎么做.
传递js语句也可以,但是这些js语句一定要是能够和json划等号的,任何夹杂了 if for = 等操作的js都是应该极力避免的.

在服务器端生成HTML的做法实在是为了照顾羸弱的浏览器而做出的让步,其实这种做法本身完全是个错误,
不过在相当长一段时间内,我们还将继续错下去.

当然我这里说的完全是ajax相关的东西,JSP、tag不在讨论范畴之内,
但我还是要补充一句: 我虽然曾大量是使用和开发tag,但我对它是非常厌恶的,
使用上也许还比较愉快,但是开发起来真够恶心的.我讨厌一切在服务器端生成html代码的行为.
关于tag这是另外一个很大的话题了,以前在javaeye上的相关讨论并不少,在这里就不再多废话了.



好了,现在该说些和标题有关的东西了(晕).
我先问几个问题:
当你要整合两个分别使用 j2ee 和 php 编写的系统时,
当你要在一个j2ee系统中使用php系统中的一部分功能时,
当你要从一个j2ee系统向另一个.net系统中传递数据时,
你会怎么做?
会变态的用java重写另外一个系统?
会更变态的将j2ee系统用php/.net重写吗?
会用j2ee生成php/.net可以理解的代码,让对方运行吗?

不会的,你首先想到的会是WS,会是MQ,会是REST,会是SOA.....


其实服务端 与 客户端 就是两个独立的系统,而且是两个独立的异构系统.
处理他们之间的关系和处理两个大型的异构系统的关系非常类似,应该咬住"服务"二字不放.
所谓"服务"应该是: 生产者提供,消费者享用.
而不是: 你告诉我我每一步要怎样做,然后我再一步步的做给你看. 这不叫服务,这叫"奴役".
任何企图在一端生成另一端代码的做法都是欠妥当的.

因为世上没有B/S系统,只有B系统和S系统.

多说一句,GWT如果设计成是在运行期生成最终html/js代码的,那么他将是愚蠢的,幸好他们没那么,但是现在的他离愚蠢也不远.


这篇文章同样比较凌乱,也不知道我说明白我想说的没.

其实我只是想告诉大家(主要是新手),应该站在服务的角度来看待系统的层次和结构,
每一层只是向其他层提供服务,并享用其他人的服务,而无权干涩别人提供的服务的细节,也不应该让别人干涉自己.
有了这样的认识,如何传递数据,如何做到系统层次件的解耦就是很自然的事情了.

当然本着"世事没有绝对,凡事都有例外"的原则,我这些观点不适用于所有系统.



以上观点只代表我个人看法(当然有一些观点不是我首创),欢迎大家提出反对意见.

评论

82 楼 renavatio 2007-09-20  

抛出异常的爱 写道

flyromza 写道

我很认同楼主的观点，server除了完成自身的逻辑之外，最多也就是为不同的client多做一些数据策略罢了（JSON、XML。。。）

虽然AJAX存在三种交互模式：数据、内容和行为，但我认为在80%+的情况下应该尽可能的使用数据交互，而内容交互与行为交互总是需要server端做一些“本该client端完成的事情”。试想，如果是这种设计逻辑，那么分层还有什么意义？关注分离还有什么意义？

分离在一开始是由于网络不稳定与传输速度的限至
现在这种限至还存在
但越来越小。
忠有一天B/S会变回C/S去的。

赞同，网速上去了，基本上就没有必要B/S了。

81 楼 deeravenger 2007-09-19  

明白楼主的意思，同时同意楼主的观点。其实web service就是这样实现的一个正面例子，但是效率不高啊。
如果当年html标准里面就包含了像树、tab、grid等等这样的东西该多好啊

80 楼 bencode 2007-09-19  

也许在以前存在着 B/S 系统，或者仅仅是 S 系统, 因为B比较简单， 或者仅是一个View

而现在是 B 系统 + S 系统

79 楼 flyromza 2007-09-19  

抛出异常的爱 写道

flyromza 写道

我很认同楼主的观点，server除了完成自身的逻辑之外，最多也就是为不同的client多做一些数据策略罢了（JSON、XML。。。）

虽然AJAX存在三种交互模式：数据、内容和行为，但我认为在80%+的情况下应该尽可能的使用数据交互，而内容交互与行为交互总是需要server端做一些“本该client端完成的事情”。试想，如果是这种设计逻辑，那么分层还有什么意义？关注分离还有什么意义？

分离在一开始是由于网络不稳定与传输速度的限至
现在这种限至还存在
但越来越小。
忠有一天B/S会变回C/S去的。

相对于“更优的职责分工”和“关注分离”而言，网络不稳定和传输速度不过是一些技术细节而已。

虽然对架构很多种看法，但分层无疑是非常成功同时被人坚持的一种，这里就包含了很多含义，远远不是纯粹技术所完全能够涵盖，就象另外一位朋友说的，团队的优化，人员的分工，这些都是软件开发中现实面临的问题，所以我认为browse与server互相独立于自己的职责是非常有必要的

78 楼 Allen 2007-09-19  

抛出异常的爱 写道

flyromza 写道

我很认同楼主的观点，server除了完成自身的逻辑之外，最多也就是为不同的client多做一些数据策略罢了（JSON、XML。。。）

虽然AJAX存在三种交互模式：数据、内容和行为，但我认为在80%+的情况下应该尽可能的使用数据交互，而内容交互与行为交互总是需要server端做一些“本该client端完成的事情”。试想，如果是这种设计逻辑，那么分层还有什么意义？关注分离还有什么意义？

分离在一开始是由于网络不稳定与传输速度的限至
现在这种限至还存在
但越来越小。
忠有一天B/S会变回C/S去的。

我想B/S与C/S的分歧不仅仅是在于网络环境的因素上……

能不能匹配团队(特别是大团队)的开发方式(人员分工, 集成管理)……

是否适应于今时今日如火如荼的外包操作……

能否改变以往比较“封闭式”的对外印象……

其实我想说的是 —— C/S一定会回来的，但那时候它的很多方面一定也会跟以往有巨大的变化(进化？)。

77 楼 mayu 2007-09-18  

你们真有时间在论坛混啊

76 楼 EnhyDra_ 2007-09-18  

现实中的交通能说明LZ的观点吧，开车与红绿灯应该就是B/S的关系吧，两者独立，到哪儿都只是数据的传递，没有掺杂一丁点的行为。。

75 楼 zkgale 2007-09-18  

谢谢,又让我学习到了一点...

74 楼 一蓑烟雨任平生 2007-09-18  

看请求的粒度有多大，如果是一个粒度很小的业务请求调用过程，应该视作一个系统，而不是两个独立的系统，主要的问题是开发成本和沟通成本会很大，项目规模一大，设计成本也会加大，项目不太好控制。

LZ确实有标题党嫌疑，我刚看到标题，还以为是骂人的话。

73 楼 抛出异常的爱 2007-09-18  

flyromza 写道

我很认同楼主的观点，server除了完成自身的逻辑之外，最多也就是为不同的client多做一些数据策略罢了（JSON、XML。。。）

虽然AJAX存在三种交互模式：数据、内容和行为，但我认为在80%+的情况下应该尽可能的使用数据交互，而内容交互与行为交互总是需要server端做一些“本该client端完成的事情”。试想，如果是这种设计逻辑，那么分层还有什么意义？关注分离还有什么意义？

分离在一开始是由于网络不稳定与传输速度的限至
现在这种限至还存在
但越来越小。
忠有一天B/S会变回C/S去的。

72 楼 flyromza 2007-09-18  

我很认同楼主的观点，server除了完成自身的逻辑之外，最多也就是为不同的client多做一些数据策略罢了（JSON、XML。。。）

虽然AJAX存在三种交互模式：数据、内容和行为，但我认为在80%+的情况下应该尽可能的使用数据交互，而内容交互与行为交互总是需要server端做一些“本该client端完成的事情”。试想，如果是这种设计逻辑，那么分层还有什么意义？关注分离还有什么意义？

71 楼 wangzhongjie 2007-09-18  

但是如果不这样处理,有什么好的办法吗

70 楼 wangzhongjie 2007-09-18  

en ,不错,很认同!!

69 楼 mingj 2007-09-17  

LZ应该就是想说‘我主要反对的是"S端生成复杂的HTML和JS给B端运行,或者B端生成JS交给S端运行"这种做法.’
然后其他的都是论据了

很明白的道理
怎么到下面反而在证明论据....

68 楼 抛出异常的爱 2007-09-17  

引用

"S端生成复杂的HTML和JS给B端运行,或者B端生成JS交给S端运行"

说的是主要是勾子行为
为了达到一种效果用勾子可以把结构变的更简单
但是勾子带来的是强烈的粘连性。
更是对代码理解的毒药。
对于这点我非常的同意；

但是有些框架使用了这种勾子
便对勾子进行了封装
包装了这种粘连，
减少了理解的困难。

这才是很多AJAX框架的主要作用。
其实从本质上来说没有ajax的框架，
一样能写出ajax的效果代码也不是很复杂。

67 楼 xwkp2008 2007-09-17  

这个应该比较符合flex的规则，视图完全由flash完成，数据通过XML在b/s之间传递，这个应该是一个b/s分离的一个极端的例子了！但由于所有的东西都是累计叠加的，大部分人还是接受b/s的部分交集

66 楼 ray_linn 2007-09-17  

香克斯 写道

如果不去过于关注标题的话，楼主的意思还是很明确的。
b/s之间只传递数据，不传递行为。
我觉得在现实中这种干不会有什么不良影响啊，而且事实上我们的ajax实现也都是进行的数据传递。
而且我们是直接传递html片段（传统的webwork返回，由freemarker生成的），获取返回数据之后客户端进行一些必要的判断，然后直接打代码贴过去。
这样的话对新手来说工作量并不大，而且很好理解。流程也容易规范起来。

我还真的不知道服务端为什么要拼装js动作来让客户端执行？而且似乎还有不少人这么做。能否有人举一些必须的传行为的例子？

第一，从帖子上看，大部分人在开发中都是只传递数据而不是传递行为。突然有人跳出来，定义了一个很大的旗子搞得大家很莫名。

第二，从帖子上看，大部分人根本不了解在什么场景下一定需要传递行为（包括LZ自己），不等于自己划了圈，在圈子里评啥优秀么？

65 楼 香克斯 2007-09-17  

如果不去过于关注标题的话，楼主的意思还是很明确的。
b/s之间只传递数据，不传递行为。
我觉得在现实中这种干不会有什么不良影响啊，而且事实上我们的ajax实现也都是进行的数据传递。
而且我们是直接传递html片段（传统的webwork返回，由freemarker生成的），获取返回数据之后客户端进行一些必要的判断，然后直接打代码贴过去。
这样的话对新手来说工作量并不大，而且很好理解。流程也容易规范起来。

我还真的不知道服务端为什么要拼装js动作来让客户端执行？而且似乎还有不少人这么做。能否有人举一些必须的传行为的例子？

64 楼 njbble 2007-09-16  

半人马 写道

这个时代就是这个样子，一篇不知所云的文章只需要有一个吓人的标题就能够赢得一大堆同样不知所云的人的追捧。

这位仁兄何必这么说，不同人知识的碰撞才能得到前进，追求更好是人类的本性，一味的使用老本只会让自己成位一台编码机器，对于你这种态度来说，讨论出来的结果根本不会对你造成影响，你认为他不知所云，我不清楚你是不屑讨论还是没有这样的水平讨论，不屑的话你大可不必来这中间插一脚，这样不仅不会增加别人对你的好感，而且还会自己贬低自己的价值。

前进的道路必然有弯路，也必然会让人回首自己走过的路，只要我们用心，也许这会改变些什么的。

63 楼 fins 2007-09-15  

这篇帖子似乎引起了一些争论 18精华 19隐藏也印证了这一点.
我只是在这里对一件很普通的事情谈了一些自己的看法,我也不想再继续争论下去了.在这里我把我的观点重新总结一下,
以便那些不愿意认真去看别人的发言,却喜欢积极的回帖的人不至于说些与本帖主题无关的话.同时我也不再对这篇文章发表评论和回复了.
想和我探讨关于js的服务端的细节问题欢迎pm.

你不应该试图在服务端的逻辑处理里 拼装出本该由客户端负责处理的逻辑.
我主要反对的是"S端生成复杂的HTML和JS给B端运行,或者B端生成JS交给S端运行"这种做法. 


我只是想告诉大家(主要是新手),应该站在服务的角度来看待系统的层次和结构, 
每一层只是向其他层提供服务,并享用其他人的服务,而无权干涩别人提供的服务的细节,也不应该让别人干涉自己. 
有了这样的认识,如何传递数据,如何做到系统层次件的解耦就是很自然的事情了.


我建议大家先在主观上把你要设计的B/S系统 看作是对两个异构系统B 和 S的融合, 
只有这样才能设计出更好的 松耦合b/s系统.

而让他们松耦合,就要先从彼此传递的数据入手, 如果传递的总是对方的代码片段,让对方去执行,这样的做法就很可怕,我主要反对的就是这种做法.


你只有在主观上先把B 和 S 分离,你才能更好的让他们在松耦合的情况下进行融合. 
所以,在设计B/S系统前,你应该忘掉你在设计B/S系统,而要把他们当成两个独立的系统来设计


当然本着"世事没有绝对,凡事都有例外"的原则,我这些观点不适用于所有系统. 

至于标题,我不认为我用了一个很夸张的标题,我只是觉得我的标题是有点"写意"不够"写实".
就好像一篇歌颂好人好事的文章标题叫做"世界充满爱" 你会去责怪道:胡说,世界依然充满了纷争!!!
就好像一篇描写全球一体华的文章标题叫做"世界是个小天地",你会去骂道:胡说!我活了一辈子了还没把中国走全呢,小个屁!!!!
总之,我不认为文章名字起的有什么问题 呵呵
(如果此贴不幸成为隐藏帖,那么我会申述, 如果成为精华帖我觉得也确实不值,因为这篇帖子更多的是说一些也许地球人都应该知道的事情----只是我觉得,实际上 很多人不知道,那些知道的人可能认为我说的是废话,所以精华的话确实对不起那些知道的人 呵呵 )


btw,在cgi asp横行的年代,很多问题是单纯的,服务端生成js,传给客户端去运行,  asp完全可以实现,但是没有人会去那么做.那时的人们习惯用简单的方法来实现简单的功能.
但是现在一切都变了,
新的技术为我们解决复杂的问题带来了方便, 但是有时却让我们在简单的问题面前迷失自己.