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


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

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

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



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

评论

22 楼 fins 2007-09-13  

ray_linn 写道

说实话，你的帖子真的很乱，我实在看不出是如何推出B系统和S系统这个结论。
所以我就跳过你所有的东西，直接讨论你的题目。

恩 确实, 有机会我重新排排版吧.

其实我的核心思想就是帖子最后那段话:

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

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

21 楼 ronghao 2007-09-13  

好文章！我想fins的意思是B系统与S系统是完全以数据为中心进行交互的，S只是负责提供数据（html,xml,json等），B负责接受数据并根据逻辑渲染然后处理页面操作逻辑，S不应该涉及与页面显示、操作有关的逻辑。
我甚至有这样的想法，B取得数据-->本地存储数据-->用户在B中对本地数据进行操作（会包括逻辑）-->操作完毕，B将数据送回S，S进行S端数据更新。
这样S会相当的simple，B会相应的膨胀。当然一次回送也会存在效率问题。

20 楼 fins 2007-09-13  

ray_linn 写道

当世界越多元，B/S的结合就越紧密。从这种意义上：server和client永远无法分割，因为只要是不同进程，就需要通讯协议。
你的公式是错的,BS之间包括了：
do what and format
what to do and format
S端提供的结果必然得以某种可以理解的格式呈现，所以B端总是从属于S端。client呼叫server都不是问题，问题是如何描述这种呼叫，所以有dcom,rmi,xml-rpc,soap...

再来说说这段

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

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

另外,你说format, 还有s与b之间必须要有一个统一的协议,一个可以互相"理解的格式".
这个你说的完全正确. 但是不能因为有了这种协议,我们就要认为S与B是一个密不可分的整体.
两个异构系统进行 soa ws...时 也是要有一个协议的 ,也是要遵循某种规则的,但是你能说这时候他们两个是一个系统吗?

当然, 你可以把任何在一起协同工作 共同完成一个目标的 很多个系统看成一个系统, 那只能说是一个宏观上的概念,不在讨论范围呢.

不能因为两者合作做一件事 就认为他们是一个系统, 不能认为两者之间有协议 有约定 就认为他们是一个系统.

就好像 你不能把 手机制造公司 和 手机配件制造公司 看成一个公司.
他们之间用共同目的,他们之间有共同的协议,他们离开对方都不能存活,但是他们终究不是一个公司,不是一个系统,他们之于对方不是不可替换的.

19 楼 ray_linn 2007-09-13  

fins 写道

ray_linn 写道

fins 写道

恩 是的 但是按你说的 那么问题的核心就由如何得到HTML表格变为如何得到那些xml了

xml是数据也是握手协议，你的客户端javascript无论如何eval传回来的东西，它本质必然是json或者xml或者text甚至可以是可执行的javascript，或者其他一些大家协商好的东西.

当世界越多元，B/S的结合就越紧密。从这种意义上：server和client永远无法分割，因为只要是不同进程，就需要通讯协议。

你的公式是错的,BS之间包括了：

do what and format

what to do and format


S端提供的结果必然得以某种可以理解的格式呈现，所以B端总是从属于S端。

完了 你更没理解我的意思, 你把问题居然引到"握手协议"上去了.

我们会到问题的开始.

z_jordon 写道

那实在是佩服你居然用你厌恶的tag把ecside做了出来,如果不用tag,同样实现ecside不知道你有什么更好的方法.在客户端使用js动态生成表格的方法吗?

然后你 说可以 用xml+xslt

然后我说 如果用xml+xslt,那么问题的关键就是xml如何生成和处理了, 因为这时候展现完全由xslt+js来实现了.

再然后 你就冒出个"xml是数据也是握手协议"

先说一说我的意思吧.
实际上 xml+xslt 和 tag js本身不是一个范畴.我用tag 也可以实现 xml+xslt的页面啊.
tag和js  都可以 生成与处理 html/xml+xslt.
你不能把 tag js 和 xml+xslt 放在一起比较.
tag实际上可以理解为就是代码工厂,就是用来生成html xml xslt的.

我和z_jordon讨论的是 "tag js ", 而你引出一个 xml xslt,显然大家讨论的不是一个范畴啊.

另外 目前还没有一个轻量级的成熟的 基于xml+xslt的列表组件 或者其他什么展现层组件.
就算有也不是很流行, 为什么呢

说实话，你的帖子真的很乱，我实在看不出是如何推出B系统和S系统这个结论。
所以我就跳过你所有的东西，直接讨论你的题目。

18 楼 cats_tiger 2007-09-13  

fins所说的“生成”不是指在jsp中的html或js代码由servlet container编译生成html或js，而是说，在s端的代码中，用out之类的方法输出代码，以前我也经常写：

pageContext.getOut().print("<script>...");

后来改用freemarker生成html或js，情况大有改观。再后来，什么都不写了。

17 楼 fins 2007-09-13  

ray_linn 写道

fins 写道

恩 是的 但是按你说的 那么问题的核心就由如何得到HTML表格变为如何得到那些xml了

xml是数据也是握手协议，你的客户端javascript无论如何eval传回来的东西，它本质必然是json或者xml或者text甚至可以是可执行的javascript，或者其他一些大家协商好的东西.

当世界越多元，B/S的结合就越紧密。从这种意义上：server和client永远无法分割，因为只要是不同进程，就需要通讯协议。

你的公式是错的,BS之间包括了：

do what and format

what to do and format


S端提供的结果必然得以某种可以理解的格式呈现，所以B端总是从属于S端。

完了 你更没理解我的意思, 你把问题居然引到"握手协议"上去了.

我们会到问题的开始.

z_jordon 写道

那实在是佩服你居然用你厌恶的tag把ecside做了出来,如果不用tag,同样实现ecside不知道你有什么更好的方法.在客户端使用js动态生成表格的方法吗?

然后你 说可以 用xml+xslt

然后我说 如果用xml+xslt,那么问题的关键就是xml如何生成和处理了, 因为这时候展现完全由xslt+js来实现了.

再然后 你就冒出个"xml是数据也是握手协议"

先说一说我的意思吧.
实际上 xml+xslt 和 tag js本身不是一个范畴.我用tag 也可以实现 xml+xslt的页面啊.
tag和js  都可以 生成与处理 html/xml+xslt.
你不能把 tag js 和 xml+xslt 放在一起比较.
tag实际上可以理解为就是代码工厂,就是用来生成html xml xslt的.

我和z_jordon讨论的是 "tag js ", 而你引出一个 xml xslt,显然大家讨论的不是一个范畴啊.

另外 目前还没有一个轻量级的成熟的 基于xml+xslt的列表组件 或者其他什么展现层组件.
就算有也不是很流行, 为什么呢

16 楼 fins 2007-09-13  

yyjn12 写道

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

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

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

不太理解.

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

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

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

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

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

不知道我说的 你明白没.

15 楼 ray_linn 2007-09-13  

fins 写道

恩 是的 但是按你说的 那么问题的核心就由如何得到HTML表格变为如何得到那些xml了

xml是数据也是握手协议，你的客户端javascript无论如何eval传回来的东西，它本质必然是json或者xml或者text甚至可以是可执行的javascript，或者其他一些大家协商好的东西.

当世界越多元，B/S的结合就越紧密。从这种意义上：server和client永远无法分割，因为只要是不同进程，就需要通讯协议。

你的公式是错的,BS之间包括了：

do what and format

what to do and format


S端提供的结果必然得以某种可以理解的格式呈现，所以B端总是从属于S端。client呼叫server都不是问题，问题是如何描述这种呼叫，所以有dcom,rmi,xml-rpc,soap...

14 楼 yyjn12 2007-09-13  

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

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

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

不太理解.

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

13 楼 fins 2007-09-13  

恩 是的 但是按你说的 那么问题的核心就由如何得到HTML表格变为如何得到那些xml了

12 楼 ray_linn 2007-09-13  

z_jordon 写道

那实在是佩服你居然用你厌恶的tag把ecside做了出来,如果不用tag,同样实现ecside不知道你有什么更好的方法.在客户端使用js动态生成表格的方法吗?

XSLT和XML配合javascript或者VBScript，照样可以生成表格。

11 楼 fins 2007-09-13  

zb1015 写道

fins 写道

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

请说明一下,那些js代码不是有服务器端生成

从你说话的口气里我感觉你的意思是 : 没有什么js代码不是服务端生成的.

如果你这样认为那只能说明我俩对"生成"这两个字的定义不同.

当然,也许按你的理解, jsp内写的所有的html和js都可以理解为服务器端生成,对吧?

10 楼 zb1015 2007-09-13  

fins 写道

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

请说明一下,那些js代码不是有服务器端生成

9 楼 fins 2007-09-13  

如果不用tag就用js, 或者直接用 <% .... %> 呵呵

其实本质上 jsp文件就是 "服务器端生成HTML"的典型
但是对于他实在很难说讨厌或是喜欢.

我想也许把 jsp看成是 b和s的中间件比较合适吧 呵呵

8 楼 z_jordon 2007-09-13  

那实在是佩服你居然用你厌恶的tag把ecside做了出来,如果不用tag,同样实现ecside不知道你有什么更好的方法.在客户端使用js动态生成表格的方法吗?

7 楼 dengyin2000 2007-09-12  

听说刚放出来的gwt1.4不错。  有机会看看去。。

6 楼 dengyin2000 2007-09-12  

fins 写道

我觉得用java写js 这种行为本身是否合适 是个值得探讨的问题
但是 我也知道 这样的问题是探讨不出什么结果的 呵呵
只能是仁者见仁了
总之我是不喜欢啦 直接写js多爽.

呵呵。  可能我javascript不太行 所以对java有些偏爱。 不过gwt对一些不熟悉javascript的人的贡献还是蛮大的。 写java比写javascript爽吧。IDE的支持强多了， 特别是Refactor。

5 楼 fins 2007-09-12  

我觉得用java写js 这种行为本身是否合适 是个值得探讨的问题
但是 我也知道 这样的问题是探讨不出什么结果的 呵呵
只能是仁者见仁了
总之我是不喜欢啦 直接写js多爽.

4 楼 dengyin2000 2007-09-12  

fins 写道

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

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

你这句怎么理解？ gwt的rpc server有生成一大堆的js让client端调用？ 我感觉gwt还是把server端跟client端分得很清楚的。 我想他只是帮你做了把java object mapping到 javascript object。 其实我还是比较喜欢gwt的这么模式。

3 楼 抛出异常的爱 2007-09-12  

引用

DWR传过来的JS,实际上的只是扮演着"service对应的url","service需要的参数","service调用结束后要做的事情"这些参数所扮演的角色.

深得精髓，不过为了卖概念就是要骗人的。骗人骗多了自己也就信了。