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

fins

浏览: 2617869 次
性别:
来自: 小胖儿的大城

最近访客更多访客>>

快了的男孩

sagadan

fancycat

u012363178

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

java & ee

应用服务器 json DWR Ajax 设计模式

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

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

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

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

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

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

分享到：

闲言碎语之 : 正确 | 我为什么选择mootools,抛弃了prototype. ( ...

2007-09-12 13:45
浏览 34446
评论(122)
论坛回复 / 浏览 (118 / 68410)
分类:企业架构
查看更多

122 楼 yuan 2008-06-27

《Expert One-On-One J2EE Development Without EJB》这本书上说

Rod Johnson 写道

J2EE开发者们中间有一种根深蒂固的认识：业务对象和web层应该在物理上分开；我认为这纯属谬见，危害极大、代价极高。

这和fins的观点有没有冲突？

我理解中的fins的观点就是把B/S程序给C/S化了，一些“表示逻辑”本是由服务端（<%%>的Java脚本，或者是一些tag）完成的，现在移到了客户端。

121 楼 norwolfli 2008-06-20

基本上理解了楼主的意思：既然有jsp可用了，就不要在servlet里out.print("<html>");了,甚至可以理解jsp相当于B,servlet相当于S。B和S要严格分离。

120 楼 kj243341578 2008-06-20

对说的很好
顶

119 楼悠游键客 2008-06-20

同意楼主的意见，每一层有每一层提供的服务，而这个服务不应该干涉别人怎么使用。
偶也很讨厌通过服务器端向客户端输入HTML和JS代码

118 楼 javaboy2006 2008-06-19

fins 写道

但我还是要补充一句: 我虽然曾大量是使用和开发tag,但我对它是非常厌恶的,
使用上也许还比较愉快,但是开发起来真够恶心的.我讨厌一切在服务器端生成html代码的行为.

深有体会，写多了tag代码后看着头晕。所以在写JavaWeb应用的时候，.jsp页面中坚决不出现<%%>服务器端代码，Servlet中也不出现类似：out.print("<table><tr><td>hello world!</td></tr><table/>");代码。B端就做B端自己的事情，S端就做S端自己的事情，互不越界。不过jsp页面最后还是被转换成Servlet然后编译成.class文件，别人本来就叫Java Server Page嘛，干脆用模板把页面静态化吧。我的理解就是按照MVC模式来开发。

117 楼 Rainbamboo 2008-06-19

那可以了，页面中的<body></body>是空的，然后全部使用请求过来的数据来填充貌似最理想的一种做法,关键是做到的又有多少?

116 楼 javaeye26b 2008-06-02

B/S指的是BROWSER与SERVER，相对于以往的C/S系统，区别在于BROWSER是一个更稳定的CLIENT。它通过以时间换空间的手段换来CLIENT端的稳定或者说一致性，是传统C/S系统中的面向服务思想上的更上一层楼。不知道有没有想过，那么在这一层上的上面，还会不会有新的一层呢。我认为有。那就是操作系统在客户端的消失。因为现在的浏览器仍然是基于OS的。要知道，除了上面所提到的，OS概念本身就在一步步淡化。最初的OS是相对于裸机而言的。但是现在的OS明显已经一步步离那个概念越来越远。进程，内存管理，或者说IE（这个已经变成OS的一部分，应该没有人反对吧），等所有并非直接访问硬件的代码都带有非OS的味道。扯远了，下面回到主题。。。

这样一来，懒人最终将获得成功，不懒的人也最终将获得成功。大家都成功了，这个世界当然会变得更美好。

从这个角度考虑的话，未来的SERVER要承担的任务会越来越重。楼主所提的B系统与S系统其实就是SERVER上面的两个子系统。一个是派出去做外合的，一个是留下来做内应的。其间提到的DWR的问题，其实就是一个解耦的问题。耦合的问题大家都知道，有好处，有坏处。关键在于两个系统之间的关系是什么样的。
比方说，你肯定不希望你跟车之间的耦合太紧，因为有时候你还是需要离开它一下，或者它有时候还是会需要离开你一下。但你在任何时候都不会希望钱离你太远！

115 楼 tangchaodong 2008-06-01

LZ在追求理想,老板在追求利润!哈哈

114 楼 Andy_Fay 2008-04-19

太长了
看了一下，其实很简单
只传递数据，不传递行为

113 楼 Ben.Sin 2008-04-13

好文，同意楼主的观点

就比如你去餐厅吃饭，你可以点一份5成或者7成熟的牛扒
但餐厅不会答应你，假如你点的菜色是红烧的水煮鱼

112 楼 kerne 2007-12-11

fins 写道

pikachu 写道

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

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

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

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

如果要这样说的话，LZ是否说得不清楚？而在别人提问后，LZ才明白自己所以表达的观点？
我支持pikachu的说法，主要是LZ的标题让大家产生了问题并且观点表示不明确。
其实S端就是s端，B端就是B端，不要把业务搞到B端去，不要把B端不美观的东西搞到S端去。
就这么简单

111 楼 bellstar 2007-12-11

虽然自己也一直推崇把前台做成不针对某种后台的可易构的客户端，但却没有深入的想到楼主所说的B系统和S系统的看法，非常感激。

110 楼 chenjf2k 2007-11-30

对于习惯javascript编程的我，对楼主的这篇文章非常认同，非常的佩服

109 楼 hred 2007-11-23

从REST的角度看

B就是负责呈现数据，传送对数据的操作的平台。

S就是一系列的定义良好的资源。（资源某种程度上跟WebService有所重合）

B应该做甚么，S应该做甚么，都应明确规定，这样避免许多设计上的胶合代码（传递，调用，匹配，别名诸如此类）。系统生命期才能更长。

108 楼 cowskin 2007-11-21

分久必和，合久必分。
没有绝对的！适应才是硬道理！

107 楼 12True 2007-11-16

abo 写道

12True 写道

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

你不觉得这地方博士太多，专家过少？

至少有一些能写出些东西
能让我停留一两小时

106 楼 protti 2007-10-26

renavatio 写道

抛出异常的爱写道

flyromza 写道

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

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

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

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

我一直感觉给机器里塞太多东西是个很蠢的办法也许以后没有C/S了都是B/S呢因为机器里不需要硬盘了也说不定一起都在服务器处理只需要一个薄薄的屏幕看结果就好了

105 楼 caoyi1983 2007-10-25

JSP,不只可以生成HTML，也可以生成XML，我想这就是AJAX里的X提示我们的，M交给S（通过JSP），V和C交给B（通过js）.

104 楼 abo 2007-10-23

12True 写道

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

你不觉得这地方博士太多，专家过少？

103 楼 s_jd 2007-10-22

好，不错

« 上一页 1 2 3 … 6 7 下一页 »

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论