世上没有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代码的,那么他将是愚蠢的,幸好他们没那么,但是现在的他离愚蠢也不远.


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

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

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



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

评论

42 楼 pikachu 2007-09-13  

fins 写道

pikachu 写道

楼主的意思就是,两个系统之间,传递的就应该是VO,不管这个VO是java的,xml的还是json的.
强烈鄙视楼主的标题!!

我的标题绝对不是标题党,只是比较"写意",

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


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

好歹我也深知你全文的精髓啊,你怎么也不吹捧一下我??

41 楼 fins 2007-09-13  

通常情况下 应该避免传递行为
通常情况下 应该尽量以数据为中心

40 楼 fyting 2007-09-13  

从标题来看，那么也可以说：世上没有B/S系统，只有C/S系统，Browser不也是一种Client？然后，完了。
看了帖子，还不大明白，lz的意思就是B-S之间只能传输数据，而不是行为？

39 楼 weiqingfei 2007-09-13  

标题显的有点儿大，不过lz的意思还是明白的，好像有点儿带有网络交互功能的Java Web Start的意思。

38 楼 fins 2007-09-13  

xly_971223 写道

fins 写道

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

ruby中的动态代码执行是不是跟这个有点类似？
我不懂ruby，有没有ruby程序员给解释一下

我也不了解 应该不一样吧
可能更想 模板语言 jsp  或者 gwt那种吧.

期待有人指点.

37 楼 fins 2007-09-13  

我主贴中那句 "世事没有绝对 凡事都有例外"
就是为了堵有这种观点的人的嘴的,可惜还是没堵上.

而且我文章中多处出现了" 应该 尽量 通常 可以"等词汇
而几乎没有 "一定 必须 非这样不可"的字眼.

同时,我发现你又把话题引到另外的范畴了

真拿你没办法 呵呵 无奈啊.

我从来没有说过你的观点是错的(而且我很明确的说过:你的观点是正确的)
你的观点没错.一直都很正确,只是和我讨论的问题没什么关系而已.

36 楼 ray_linn 2007-09-13  

fins 写道

其实小事情也能反应出大问题

只是我所反应出的大问题 引起了你在理解上的错误
我只好把问题的高度降低了.

你要是不愿意,那我再把问题的高度提升一些:

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

这么说扣题了吧?
说复杂了你不理解,说简单了你说我标题党 ,唉 做人难啊

松耦合不是万能，也不是每个项目都必要的。

事实上按你的说法：典型的Template系统是松耦合还是紧耦合？

35 楼 piaoling 2007-09-13  

B/S通信本应该只停流在数据传递上

34 楼 fins 2007-09-13  

其实小事情也能反应出大问题

只是我所反应出的大问题 引起了你在理解上的错误
我只好把问题的高度降低了.

你要是不愿意,那我再把问题的高度提升一些:

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


这么说扣题了吧?


说复杂了你不理解,说简单了你说我标题党 ,唉 做人难啊

33 楼 ray_linn 2007-09-13  

fins 写道

为了让你更好的明白我的意思, 我把我的观点的高度下降一些, 把语言说的再直白一些:

请各位新同学,不要在S端生成复杂的JS代码传递给B端执行, 更不要在B端生成JS代码交给S端运行,这么做是在绝大多数情况下是不对的.

如果我这么说了, 你还是拿"握手协议 报文"来说事,那我就真是无话可说了.

你要谈的东西很小，近似是设计范式的问题，却扯了面很大的旗。标题党么？俗话说扯虎皮当大旗是也。

一个很大很大的标题，放一个很小小的东西，不意外有人会误解。

32 楼 xly_971223 2007-09-13  

fins 写道

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

ruby中的动态代码执行是不是跟这个有点类似？
我不懂ruby，有没有ruby程序员给解释一下

31 楼 fins 2007-09-13  

pikachu 写道

楼主的意思就是,两个系统之间,传递的就应该是VO,不管这个VO是java的,xml的还是json的.
强烈鄙视楼主的标题!!

我的标题绝对不是标题党,只是比较"写意",

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


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

30 楼 fins 2007-09-13  

ray_linn 写道

xly_971223 写道

b端----->发送数据包到服务端
s端----->处理b端数据包，结果返回b端 ----->S端如何理解数据报文？
进一步抽象为
b端----->发送url
s端----->返回数据（数据格式可自定义）------->B端如何理解数据报文

所以B/S握手基于相同协议是不可或缺的，S提供Json，B就得服从Json，S从Json改成Soap，B端就得改。

这就牵涉到 编码/传输协议/系列化/反系列化，甚至还有压缩，认证等等问题，远不是这么简单。

你所说的一切 和我所要表达的:
你不应该试图在服务端的逻辑处理里 拼装出本该由客户端负责处理的逻辑.
有冲突吗??  别说冲突,其实一点关系都没有,我觉得你好像和我讨论的不是一个问题.

你别总上拿握手协议 报文什么的说事,弄的挺吓人的,那些我都不懂

其实你的观点就是
"设计B/S系统时应该把他们当成一个系统来设计,因为他们必须要在某种约定 某种协议下共同工作"
我对你的观点理解正确吗??

那我问你, 如果B端设计上的每一次变化 都会引起 S端的大变革, 或者S端的大变动都会让B端必须做出较大的调整,这样的设计是合理的吗?
B 和S 应该尽可能的解耦 有错吗?

如果你认为合理,认为有错 那你可以关闭此页了.

如果你认为不合理,认为没错, 那么你在设计"某种约定 某种协议"时,是不是也应该考虑到 松耦合性?


而我所在讨论的,就是我们应该站在怎样的角度来设计出松耦合的"某种约定 某种协议",
其实说了半天,我只是在探讨最基本的松耦合的设计问题:

你只有在主观上先把B 和 S 分离,你才能更好的让他们在松耦合的情况下进行融合.

其实你我关于b/s系统的观点都没有错.

错的是 你没有理解我要表达的意思.而我没有让你明白我要表达的意思


为了让你更好的明白我的意思, 我把我的观点的高度下降一些, 把语言说的再直白一些:

请各位新同学,不要在S端生成复杂的JS代码传递给B端执行, 更不要在B端生成JS代码交给S端运行,这么做是在绝大多数情况下是不对的.

如果我这么说了, 你还是拿"握手协议 报文"来说事,那我就真是无话可说了.

29 楼 pikachu 2007-09-13  

楼主的意思就是,两个系统之间,传递的就应该是VO,不管这个VO是java的,xml的还是json的.
强烈鄙视楼主的标题!!

28 楼 hax 2007-09-13  

楼主的意思是好的，就是有一点点标题党。

当然，楼主说的不可能适用于所有应用。对于大多数企业应用来说，它最好别分什么BS，完成功能最重要。而对于mashup应用，当然B是B，S是S啦。甚至还有本地应用，例如……单机游戏！B为主，S为从的说……

回头说说服务器发送js这个事情。抛开应用类型不谈，偶赞同把js限制在有限的范围内。一个是json，即作为一种数据传送格式。另一个是push功能的协议，主要是为了comet，以及可以解决跨域的问题。

27 楼 xly_971223 2007-09-13  

ray_linn 写道

xly_971223 写道

b端----->发送数据包到服务端
s端----->处理b端数据包，结果返回b端 ----->S端如何理解数据报文？
进一步抽象为
b端----->发送url
s端----->返回数据（数据格式可自定义）------->B端如何理解数据报文

所以B/S握手基于相同协议是不可或缺的，S提供Json，B就得服从Json，S从Json改成Soap，B端就得改。

这就牵涉到 编码/传输协议/系列化/反系列化，甚至还有压缩，认证等等问题，远不是这么简单。

基于http协议这个是肯定的 否则我们在这儿讨论bs就没有意义了
另外我想提一点，服务端提供什么 客户端就使用什么这个毋庸置疑的，任何系统都是这样
但是在bs系统中b端并不是只能被动的接受服务端的数据格式，在http request头中有一个

Accept:text/xml, application/xml , application/xhtml+xml

通过对accept的设置可以定制s端的返回格式，这样不同的客户端就可以根据需要获取数据
ps：bs要实现分离确实远不是这么简单，现在也仅仅是探索阶段

26 楼 抛出异常的爱 2007-09-13  

fins 写道

yyjn12 写道

Brower 最大的用途不就是把服务器发送过来的html代码展现出来吗?

避免一切在服务器端生成客户端代码的行为,那怎么玩啊?

b端发出一个请求,s端响应请求,传回一个文本,这个文本就是一段html吧,最常见的情况.这个html就是包含了数据和样式.数据肯定是在服务器生成的吧,样式难道让s端随意展现?

不太理解.

.本来没资格在这个有"门槛"的社区发言的.不过这个问题的思想话我的确想弄明白.

你和刚才那位一样, 对我所说的 "服务端" "客户端" "生成" 这三者和你们理解的不一样.

你把 服务端 理解为 那他为我们提供服务的那台机器了.

确实,我们按你的理解, B端看到的一切 接收到的一切 都是S端发出的.

但是 我这里的 服务端确切的说 是服务端的业务逻辑, 而不是服务器.
也就是说我的意思是 
你不应该试图在服务端的逻辑处理里 拼装出本该由客户端负责处理的逻辑.

不知道我说的 你明白没.

从历史方面看
能用js写重用的人少之又少
而用java写出重用的人还是比较多的
而且在服务端写这种拼装句的话
更灵活一些。

烂用的例子很多。。。我没说它们。

25 楼 ray_linn 2007-09-13  

xly_971223 写道

b端----->发送数据包到服务端
s端----->处理b端数据包，结果返回b端 ----->S端如何理解数据报文？
进一步抽象为
b端----->发送url
s端----->返回数据（数据格式可自定义）------->B端如何理解数据报文

所以B/S握手基于相同协议是不可或缺的，S提供Json，B就得服从Json，S从Json改成Soap，B端就得改。

这就牵涉到 编码/传输协议/系列化/反系列化，甚至还有压缩，认证等等问题，远不是这么简单。

24 楼 ray_linn 2007-09-13  

fins 写道

我从来没说过 server和client可以分割, 我也从来不认为 B系统 和 S系统 可以离开对方独立运行.(也许有人会说:那他们就应该是一个系统 呵呵 那只能说你对系统的理解比我的理解更宏观.)
虽然B系统 和 S系统一定要配合使用,但是两者应该做到: 我的B系统进行改造, S系统不用作改动,即使改动,也应该是配置级的,而不应该是代码级的.反之毅然. 理想的一个S端显然是 可以配合各种个样的B的.这个想法不是我首创的, 而且这个想法实际上就是 j2ee的一个使命啊.

两个异构系统进行SOA通讯的时候，从业务的角度上看，它们确实是一个系统，为了某个共同的业务目的，A系统和B系统是系统的两个组件，这点我们既然着眼点不同，那就不需在辩论。

你既然承认BS是一定要协同的，那何来B系统和S系统，二者本来就不可分，这是我对你题目的不解。达到你所描述的理性状态，无非就是用某种自描述协议来解耦合，但是从成本效果上分析并不具太大价值。


或者你应该开卷明义，先把你认为的B系统和S系统划个边界先，如果就某人提到的S端不应拼装javascript，那这点我同意，但我认为S端可以封装javascript---如asp.net ajax.

23 楼 xly_971223 2007-09-13  

引用

我不是否定 或是辩驳 更不是争论 我只是希望在某个问题上充分的表达出自己的想法,而不是要证明谁对谁错 呵呵

我倒是希望楼主有自己的观点，事情越辩越明，没有明确的观点是不可取的，最后的结果很可能沿着别人的思路走了，丧失了很多独立思考的成份，废话不多说，言归正传。
我认为b端和s端是可以分开的
抽象出来看b端和s端
b端----->发送数据包到服务端
s端----->处理b端数据包，结果返回b端
进一步抽象为
b端----->发送url
s端----->返回数据（数据格式可自定义）
就是一个调用 返回的过程。
跟普通程序里面的方法调用有什么区别吗？普通的方法是这样调用

User user = findUser(username);

而bs结构是这样调用

Browser result = getServerData( url );

有区别吗？没有
所有说我们的server端完全可以做成像方法一样，你发送url过来我就给你返回数据 管你客户端是新浪还是sohu，是中国还是美国。
说到这里还有一个不得不提的安全问题，服务端应该可以禁止或允许某些客户端的调用