世上没有B/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有理解上的分歧了～
  

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

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

这篇帖子似乎引起了一些争论 18精华 19隐藏也印证了这一点.
我只是在这里对一件很普通的事情谈了一些自己的看法,我也不想再继续争论下去了.在这里我把我的观点重新总结一下,
以便那些不愿意认真去看别人的发言,却喜欢积极的回帖的人不至于说些与本帖主题无关的话.同时我也不再对这篇文章发表评论和回复了.
想和我探讨关于js的服务端的细节问题欢迎pm.

你不应该试图在服务端的逻辑处理里 拼装出本该由客户端负责处理的逻辑.
我主要反对的是"S端生成复杂的HTML和JS给B端运行,或者B端生成JS交给S端运行"这种做法. 


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


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

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


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


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

至于标题,我不认为我用了一个很夸张的标题,我只是觉得我的标题是有点"写意"不够"写实".
就好像一篇歌颂好人好事的文章标题叫做"世界充满爱" 你会去责怪道:胡说,世界依然充满了纷争!!!
就好像一篇描写全球一体华的文章标题叫做"世界是个小天地",你会去骂道:胡说!我活了一辈子了还没把中国走全呢,小个屁!!!!
总之,我不认为文章名字起的有什么问题 呵呵
(如果此贴不幸成为隐藏帖,那么我会申述, 如果成为精华帖我觉得也确实不值,因为这篇帖子更多的是说一些也许地球人都应该知道的事情----只是我觉得,实际上 很多人不知道,那些知道的人可能认为我说的是废话,所以精华的话确实对不起那些知道的人 呵呵 )


btw,在cgi asp横行的年代,很多问题是单纯的,服务端生成js,传给客户端去运行,  asp完全可以实现,但是没有人会去那么做.那时的人们习惯用简单的方法来实现简单的功能.
但是现在一切都变了,
新的技术为我们解决复杂的问题带来了方便, 但是有时却让我们在简单的问题面前迷失自己.

这位仁兄何必这么说，不同人知识的碰撞才能得到前进，追求更好是人类的本性，一味的使用老本只会让自己成位一台编码机器，对于你这种态度来说，讨论出来的结果根本不会对你造成影响，你认为他不知所云，我不清楚你是不屑讨论还是没有这样的水平讨论，不屑的话你大可不必来这中间插一脚，这样不仅不会增加别人对你的好感，而且还会自己贬低自己的价值。

前进的道路必然有弯路，也必然会让人回首自己走过的路，只要我们用心，也许这会改变些什么的。

如果不去过于关注标题的话，楼主的意思还是很明确的。
b/s之间只传递数据，不传递行为。
我觉得在现实中这种干不会有什么不良影响啊，而且事实上我们的ajax实现也都是进行的数据传递。
而且我们是直接传递html片段（传统的webwork返回，由freemarker生成的），获取返回数据之后客户端进行一些必要的判断，然后直接打代码贴过去。
这样的话对新手来说工作量并不大，而且很好理解。流程也容易规范起来。

我还真的不知道服务端为什么要拼装js动作来让客户端执行？而且似乎还有不少人这么做。能否有人举一些必须的传行为的例子？

第一，从帖子上看，大部分人在开发中都是只传递数据而不是传递行为。突然有人跳出来，定义了一个很大的旗子搞得大家很莫名。

第二，从帖子上看，大部分人根本不了解在什么场景下一定需要传递行为（包括LZ自己），不等于自己划了圈，在圈子里评啥优秀么？

这个应该比较符合flex的规则，视图完全由flash完成，数据通过XML在b/s之间传递，这个应该是一个b/s分离的一个极端的例子了！但由于所有的东西都是累计叠加的，大部分人还是接受b/s的部分交集

说的是主要是勾子行为
为了达到一种效果用勾子可以把结构变的更简单
但是勾子带来的是强烈的粘连性。
更是对代码理解的毒药。
对于这点我非常的同意；

但是有些框架使用了这种勾子
便对勾子进行了封装
包装了这种粘连，
减少了理解的困难。

这才是很多AJAX框架的主要作用。
其实从本质上来说没有ajax的框架，
一样能写出ajax的效果代码也不是很复杂。

LZ应该就是想说‘我主要反对的是"S端生成复杂的HTML和JS给B端运行,或者B端生成JS交给S端运行"这种做法.’
然后其他的都是论据了

很明白的道理
怎么到下面反而在证明论据....