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


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

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

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



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

评论

62 楼 半人马 2007-09-15  

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

61 楼 jackyz 2007-09-14  

fins 写道

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

好奇的八一句卦。分享下，那个系统怎么个“可怕”法？
最近正在考虑“ServerSide JS 的可能性”。

60 楼 sslaowan 2007-09-14  

fins 写道

yyjn12 写道

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

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

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

不太理解.

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

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

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

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

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

不知道我说的 你明白没.

   其实您所谓的C（或者是B）指的就是表现层，包括处理用户指令和展现表现内容，在Web应用中就是指Web层呗～所谓的应用控制层也是属于这一层的，具体而言就是MVC框架中的VC；而您所谓的S，指的应该是业务服务层，可以是Service，也可以是Bussiness Facade。这样理解没错吧？
   如果是这样的话，DWR的做法就是把应用控制层挪到了客户端处理，而Struts之类的是把这种处理放在了Web服务器上，但是在逻辑上，都是属于您所谓的C。其实按照传统的J2EE分布式架构，Web层或许就应该是指Web浏览器和Web服务器两部分，而业务逻辑放在应用服务器上，通过EJB Facade调用服务。不过现在很多情况下Web服务器和应用服务器在物理上都是在一起的，所以就会将物理和逻辑的概念混淆。
   而使用Web Service代替EJB，或者是将Delphi等应用程序使用WS进行封装发布，就是鲜明的服务提供者与服务消费者的例子了。
   如果是这样的话，我赞成您的观点，不过在Web应用中，将控制器放在客户端的JS中似乎面临难于测试，过于复杂的问题（好的方式可能是在客户端实现MVC，但是很复杂）。而在桌面客户端的应用中，就好一些。

   不过我认为B/S系统似乎是一个学术界专有名词，其中的B就是指浏览器，而S就是指服务器，都是物理上的划分，这也就难免您和很多javaeyer有理解上的分歧了～
  

59 楼 xly_971223 2007-09-14  

hover1215 写道

你去看看那些大公司的包含web应用的产品。象ibm，的commerce。
全都是清一色的这种模式，java代码 生成 js。
这好象已经是产品的一种约定了。
我不是很清楚是否必须要这样做，才能满足它的期望。
但肯定给人感觉比较牛啊。）

服务端生成js就很牛？
服务端生成js有时候确实很方便 相信很多人也这样写过 可以理解
但是客户端发送js让服务端执行我十分不理解，有什么样的功能非要js才能实现，难道java不能实现吗？
就不怕客户端写个病毒毁掉服务器吗？

58 楼 jjx 2007-09-14  

不能一概而论, 开发一个完全分布式的应用程序(像这里基于soa)快,还是开发一个传统的应用来的快

再说,很多时候并不需要这种纯粹的东西,不要忘了,当初spring 是如何对待分布式的

57 楼 hover1215 2007-09-14  

你去看看那些大公司的包含web应用的产品。象ibm，的commerce。

全都是清一色的这种模式，java代码 生成 js。

这好象已经是产品的一种约定了。

我不是很清楚是否必须要这样做，才能满足它的期望。

但肯定给人感觉比较牛啊。）

56 楼 抛出异常的爱 2007-09-14  

agile_boy 写道

尤其赞成服务分开的观点，系统模块之间，本来就应该各做各的事情。

分开的话，同一个工程放入的劳动力就会翻倍，速度加快，钱的运转周期会缩短，可以使风险减低。

55 楼 agile_boy 2007-09-14  

尤其赞成服务分开的观点，系统模块之间，本来就应该各做各的事情。

54 楼 jjx 2007-09-14  

文字游戏而已

53 楼 zjumty 2007-09-14  

xly_971223 写道

客户端传js给服务端执行，其安全行怎么保证？

只让安全的人运行客户端...

52 楼 zjumty 2007-09-14  

fsword 写道

我理解你的意思差不多就是REST了，如果是这个意思那我同意。以前干过很多用一种语言拼装另一种语言的事情（最变态的是用domino的公式生成html表格，里面还要有一些简单的js脚本），现在想来非常丑陋。

为什么我们会被迫这么做？根子就在于我们把B和S看成一个整体，解耦的不够，导致开发的时候需要一个人同时熟悉两种以上的语言（也就是两种以上的思维习惯），例如java和js，于是很多java程序员就抱怨“js怎么这么难写”。

在对日外包公司,很多时候新来的员工都是按照设计书上一笔一划的copy,或者copy别人的代码.我遇到过一些新手分不清哪些代码是B端的,哪些是S端的,于是会出现Java和JS中的变量混着用的情况.包括公司的领导也要求在做一个项目的架构时,尽量不要让开发人员写js,什么都是tag把js包装.于是生成到浏览器的html非常乱.

51 楼 xly_971223 2007-09-14  

客户端传js给服务端执行，其安全行怎么保证？

50 楼 lihengxin 2007-09-14  

既然存在,就有它的合理性.

49 楼 抛出异常的爱 2007-09-14  

从一个极端到另一个极端的碰撞中，一个技术会找到其生存的空间与位置。

48 楼 fsword 2007-09-14  

我理解你的意思差不多就是REST了，如果是这个意思那我同意。以前干过很多用一种语言拼装另一种语言的事情（最变态的是用domino的公式生成html表格，里面还要有一些简单的js脚本），现在想来非常丑陋。

为什么我们会被迫这么做？根子就在于我们把B和S看成一个整体，解耦的不够，导致开发的时候需要一个人同时熟悉两种以上的语言（也就是两种以上的思维习惯），例如java和js，于是很多java程序员就抱怨“js怎么这么难写”。

作为对比，再看看C/S系统，可能server端你要熟悉spring/hibernate，而client端要熟悉swing或者其它什么，实际上也是不同的知识结构，但是一般的设计者都会先明确定义好前后端的接口API，然后就可以让不同的人做不同的方面了──当然，肯定还有互相影响的地方，但是总的来说会简单很多。

http 协议不是通常意义上的传输协议，它定义的是REST（Representational State Transfer），我认为更恰当的说法是我们可以基于http定义B/S的前后端接口API，然后server端和browser端开发人员各司其职。

完全这么做当然是理想化的，但是朝这个方向努力确实会简单许多。

PS：现在的Flex可能更容易达到这种效果，因为它就是c/s开发，只不过是在浏览器上的c/s，这方面不熟，召唤达人补充。

47 楼 fins 2007-09-13  

可能我的说法有点误导你了

服务端运行js是完全可以的,但是这段js代码应该在S端内部拼装,并且执行.从客户端得到的应该是拼装js语句所需要的必要的条件,而不应该是拼装好的JS代码.

当然这是理想状态,实际上有时候有些需求 就是要求在客户端写js语句,后台运行客户在前台写的js,那就无能为力了,那就属于我所说的例外.

例如有这样一个需求:
用户在浏览器的textarea框内 写如公式,然后服务器端根据公式来计算结果.
这个最好的做法就是让用户用js的语法写公式,我们后台得到这个公式,用rhnio来执行.如果不这么做,你后台必须要写一个语法解析和编译器了,那就太难了.

所以不是这么做不可以,而是要清除这种做法是所有做法里最合适的了

46 楼 likeblood 2007-09-13  

很赞成的搂主的说法，很多事情的责任要分清楚，不管是B还是S
不过我有个问题就你说js传到rhino是个可怕的事情是怎么回事？
我公司正打算这样做，我虽然不赞成，但是也没有有力的证据

45 楼 hyhongyong 2007-09-13  

rehte 写道

说白了，还是数据与信息的关系。
数据是信息的载体，单纯的数据不表达任何信息，数据需要某种规则解释为特定信息。
服务器端传来的数据由客户端的浏览器(HTML渲染引擎，JavaScript动态解析）解释成特定的信息展现。如果将解释规则（javascript/html代码）也嵌入到数据中，传递来数据本身就有了信息展现的含义。这造成了数据与信息展现的紧耦合，不符合MVC提倡松耦合精神。
B和S是整个有机系统的两个端点，它们的代码设计如果符合松耦合的设计，那么B和S就既能独立成系统，又可以组成有机系统。如果它们不符合松耦合的设计，比如返回JS/html的做法，就会使得B/S系统的两个子系统难以独立出来。
所以楼主说没有B/S系统，只有B系统和S系统的说法不过是理想情况下，设计良好的系统所具有的特性。

解释的好清清楚楚！！

44 楼 rehte 2007-09-13  

说白了，还是数据与信息的关系。
数据是信息的载体，单纯的数据不表达任何信息，数据需要某种规则解释为特定信息。
服务器端传来的数据由客户端的浏览器(HTML渲染引擎，JavaScript动态解析）解释成特定的信息展现。如果将解释规则（javascript/html代码）也嵌入到数据中，传递来数据本身就有了信息展现的含义。这造成了数据与信息展现的紧耦合，不符合MVC提倡松耦合精神。
B和S是整个有机系统的两个端点，它们的代码设计如果符合松耦合的设计，那么B和S就既能独立成系统，又可以组成有机系统。如果它们不符合松耦合的设计，比如返回JS/html的做法，就会使得B/S系统的两个子系统难以独立出来。
所以楼主说没有B/S系统，只有B系统和S系统的说法不过是理想情况下，设计良好的系统所具有的特性。

43 楼 dengyin2000 2007-09-13  

想web service， Service端不用知道client端是用什么实现的。。