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


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

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

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



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

评论

102 楼 12True 2007-10-21  

完完整整的看完了，蛮喜欢Javaeye的这种氛围

101 楼 12True 2007-10-21  

fins 写道

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

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

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

你只有在主观上先把B 和 S 分离,你才能更好的让他们在松耦合的情况下进行融合.
所以,在设计B/S系统前,你应该忘掉你在设计B/S系统,而要把他们当成两个独立的系统来设计
这么说扣题了吧?
说复杂了你不理解,说简单了你说我标题党 ,唉 做人难啊

你早这么说，我就不会看到40几楼了。
还好你没一开始这么说
lz精神可嘉，继续发扬啊。关注ing

100 楼 12True 2007-10-21  

ray_linn 写道

fins 写道

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

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

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

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

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

其实那些很多很多钻石的牛人

讨论的帖子

就是让我们咬的，咬到只剩下很小很小的原理

在咬的过程当中，我们就吃饱了。顺便赞一句，这个汉堡比较大。

我们本来就是那样的，你最牛，也不过0和1

99 楼 12True 2007-10-21  

lihengxin 写道

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

不应该是合理性

应该是无奈性

开发的时候还要加上人性

98 楼 12True 2007-10-21  

pikachu 写道

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

是很可怕

封装tag的时候实在太恶心了

貌似又深入的了解了点

收回我楼上的话。

呵呵

97 楼 12True 2007-10-21  

至于应该不应该在S端拼凑js，html代码
我暂时还没有什么想法

因为js实在是郁闷。
用java写多舒服。。
呵呵

96 楼 12True 2007-10-21  

初看，还真是标题党
看到32L
貌似lz还真有点诗意。
还真不是一般技术人员能达到的

我的理解是
尽可能的把b端和s端看作独立的系统
也就是所谓的尽可能的松 BS之间的耦合
但是BS之间又必须遵循B和S之间的达成的某种协议，或者说标准吧。
实在不喜欢用“标准” 这个词。

貌似我和没说，没理解一样 - -#

95 楼 sslaowan 2007-10-20  

Sean220 写道

在我的努力下应用页面也全是HTML了，利用MSXMLHTTP与后台页面用XML通讯数据。
    那么协议就是包含了控制信息的业务数据格式化后的结果，那么回到AJAX系统，PAGE/B端与Server端看作两个系统的话，一个设计良好的WEB系统，重点考虑的部分就是协议的制订，这样就被迫程序员连带着去理解HTTP是这么一种无状态的协议，以前后台两个系统的思维方式来设计WEB系统，应该会事半功倍。可以少犯一些构架上难以补救的错误。

    我在想，这是不是就是REST的思想。B端就是HTML+CSS+Javascript，然后“按需代码”从服务器端Download Applet或者Flash加以扩充，中间的协议就是HTTP。

94 楼 lewisou 2007-10-18  

fins 写道

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

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

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

确实需要有一层来生成html，做到系统各层解耦。 但我认为是代码逻辑的分层，而不是物理意义上的分层（B端还是S端）。所以用jsp生成html我认为没有任何问题。

93 楼 liusong1111 2007-10-12  

楼主的意思是质疑DSL生成的javascript，如果除了要展现的数据，还包括UI控制逻辑会造成的问题。
因为标题起的不清，造成开始误解不断，后面又跑题老远~
ruby的RJS也面临同样的问题：
http://liusong1111.iteye.com/post/332560
http://liusong1111.iteye.com/post/332575

看看TrimJunction的走势，想想web应用与google gears结合的难点，品品REST支持多format的能力，可以推想楼主质疑的方向是正确的，另外web开发中还有待突破的地方是，view层在浏览器和服务器端 需要一个统一的模板语言，"write once,run client or server"，当然会涉及一些深层次的东西，如permission, VO。

92 楼 wplqw 2007-10-11  

Jdon有一篇文章,说的意思与lz类似.
http://www.jdon.com/article/31136.html

91 楼 phantomhu 2007-10-11  

<font>经过初期使用浏览器的简单的浏览方式后 所谓的BS的系统也在想CS系统进行回归， 考虑的实际网络情况、性能和外观的需要<br/>
对于B端的要求也越来越高，使用AJAX后其功能丰富性也已经不亚于C了。<br/>
随着网络操作系统的发展B和C是可以很好的找到的一个融合点，很多应用在根本上都是些本质相同的东西。</font>

90 楼 darkjune 2007-09-29  

0耦合基本没有系统能达到吧,只要把易变的业务隔开就好了啊

89 楼 realorg 2007-09-26  

要做到B端和S端的零耦合真的很难～！

其实，连Struts的验证框架不是也在服务器端生成 Js脚本，再用<html:javascript/>来在客户端验证的么？

我想我们应该提倡 B系统和S系统 的低耦合。
不是有句话：“存在的都是'合理'的～！”。
基于种种原因，如成本资金、技术实现、性能调优等，实现零耦合短期内是很不现实的～！

88 楼 linginfanta 2007-09-24  

有点哗众取宠。

87 楼 IamNull 2007-09-23  

非常认同楼主的观点！赞一个！呵呵

之前，自己做一个小玩意，由于没有想清楚到底做成B/S or C/S, 所以，两种都作。等于把楼主要说的，想了一遍。。。

对于，S 端提供业务逻辑， B端提供表现， 然后B端提供原始输入，要求得到某些数据，不管B端采用什么，是 Broswer 还是 Swing App 都可以。。

关键就是楼主说的，把B系统与S系统当作两个独立的系统来设计，来考虑！
呵呵，至于楼主所说的，差异化，肯定存在。。

如果有不同意见，呵呵，也是正常的。每个人的经历不同，想法当然不同。。

86 楼 0000 2007-09-21  

renavatio 写道

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

B/S存在的原因不是网速，是运算能力

85 楼 0000 2007-09-21  

看了一点，觉得LZ的意思是C/S化的B/S，中否？

84 楼 baallee 2007-09-21  

纯技术人员的观点。站在赚钱的角度，简单易用，成本低廉是最佳选择，不会在行你用什么。

83 楼 Sean220 2007-09-20  

这么多年的项目做下来，居然从来没有用过JSP，也算是另类了，记得01还02年的是招WEB程序员，给新员工讲技术架构，当时还没有AJAX正统的名字，只是自己做程序员的时候对<%%>和服务端生成HTML非常痛恨，那个时候虽然后台是ASP，但在我的努力下应用页面也全是HTML了，利用MSXMLHTTP与后台页面用XML通讯数据。
   种做法非常另类，往往新员工很长时间才能熟悉其中的概念，都是写<%%>太多了，鲜有对前后台分的很清楚的，把B当一个应用，把S端的页面当一个接收POST/GET请求提供业务数据而不管显示的Servive，其实养成这种习惯对后来的WS,SOA的理解都大有好处。后来的系统在前台页面动的比较少的情况下移植到J2EE上，servlet代替了服务页面，也就再也没机会用到JSP了，那段日子最头痛的就是开发人员JS水平普遍太差、以及处理传输过程中的乱码问题。
   在win32平台上作过com+应用的都知道，当服务端com+组件增加或修改接口，由于要重建proxy 和stub 信息，client机上要重新安装类型注册信息，这样的问题在多数服务组件粒度先天设计不良的情况下，系统难以维护，效率低下，所以dwr这种类似的生成js接口代码的方式，只会使前后台代码偶合度更高，而没有站在B\S是两个系统的角度考虑问题，而是在努力使程序员忘记通讯协议，忘记这是一个通讯转发的过程，其做法与com+如出一辙，EJB/cobra的rmi调用也是java世界的同样演绎。
   后来WS横空出世，其实没什么新鲜东西，舞台从LAN搬到了Internet，WSDL就是stub/proxy的描述文件代理了类型文件，client同样是要生成本地语言接口文件，使我这个长期以来使用非标准soap（自定义XML结构）协议的人有点看不惯，当然WS的粒度都先天性比较粗，上面提到的问题会好一点，原本设计方向也主要也是不同机构之间电子商务应用的功能级调用，如果谁在LAN环境下说要利用WS构架做应用开发，也以细粒度来重蹈COM+覆辙，那么恭喜，脑子肯定进水了。说实在的，我到现在都还认为SOAP的前身XMLRPC协议的设计更加简洁而幽雅，比SOAP各个版本升级争先恐后地增加体积（如同prototype的变味）要来的好多了。
   讲了那么多，其实隐约有点离题了，但看到楼主这比较合我心意的论调，只要多说两句，觉得既然WS再这么变本质都会回到臃肿的SOAP协议封装的XML字符串来进行通讯，那么做出上述设计，只能是为了照顾传统习惯了已紧耦合写C/S系统的开发人员，过度时期的无奈之举。但如果让程序员继续懵懂下去，把不同系统的集成来当一个系统来开发，我想跑偏是迟早的事情。
  回到BS系统，传统的几个WEB框架，这里就不署名了，只要是有意模糊MVC里V的那一层，认为是可以在服务端完成的所有事情的，总是会有这样的毛病。那么JSF，最近也参加kingtee的opreamask发布会，这么多评价里认为比较中肯的就是，不要以为什么事情都可以用J2EE的方式来解决，LZ自己作过tag，应深有体会。
   HTML的版本发展历史也是一个痛苦矛盾的过程，一方便想把内容和显示都搞定，一方面又想把内容和显示能分离，于是又无奈中出了CSS。现在就会听到老手的拳拳之言，尽量让CSS来管渲染样式，让HTML更XML一点，更数据一点。那么回到AJAX也可以这么讲，让交互的东西更数据一点，表把HTML/JS代码传来传去，OK?
   这几年重点参与了一些以异构系统信息整合的类EAI平台设计，如果说要有体会，也就协议二字。两个系统之间为了能互相明白对方而做的通讯约定叫做协议，课本里大致这样名词解释的。那么协议就是包含了控制信息的业务数据格式化后的结果，那么回到AJAX系统，PAGE/B端与Server端看作两个系统的话，一个设计良好的WEB系统，重点考虑的部分就是协议的制订，这样就被迫程序员连带着去理解HTTP是这么一种无状态的协议，以前后台两个系统的思维方式来设计WEB系统，应该会事半功倍。可以少犯一些构架上难以补救的错误。