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

你所说的一切 和我所要表达的:
你不应该试图在服务端的逻辑处理里 拼装出本该由客户端负责处理的逻辑.
有冲突吗??  别说冲突,其实一点关系都没有,我觉得你好像和我讨论的不是一个问题.

你别总上拿握手协议 报文什么的说事,弄的挺吓人的,那些我都不懂

其实你的观点就是
"设计B/S系统时应该把他们当成一个系统来设计,因为他们必须要在某种约定 某种协议下共同工作"
我对你的观点理解正确吗??

那我问你, 如果B端设计上的每一次变化 都会引起 S端的大变革, 或者S端的大变动都会让B端必须做出较大的调整,这样的设计是合理的吗?
B 和S 应该尽可能的解耦 有错吗?

如果你认为合理,认为有错 那你可以关闭此页了.

如果你认为不合理,认为没错, 那么你在设计"某种约定 某种协议"时,是不是也应该考虑到 松耦合性?


而我所在讨论的,就是我们应该站在怎样的角度来设计出松耦合的"某种约定 某种协议",
其实说了半天,我只是在探讨最基本的松耦合的设计问题:

你只有在主观上先把B 和 S 分离,你才能更好的让他们在松耦合的情况下进行融合.

其实你我关于b/s系统的观点都没有错.

错的是 你没有理解我要表达的意思.而我没有让你明白我要表达的意思


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

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

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

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

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


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

ruby中的动态代码执行是不是跟这个有点类似？
我不懂ruby，有没有ruby程序员给解释一下

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

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

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

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

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

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


这么说扣题了吧?


说复杂了你不理解,说简单了你说我标题党 ,唉 做人难啊

B/S通信本应该只停流在数据传递上

松耦合不是万能，也不是每个项目都必要的。

事实上按你的说法：典型的Template系统是松耦合还是紧耦合？

我主贴中那句 "世事没有绝对 凡事都有例外"
就是为了堵有这种观点的人的嘴的,可惜还是没堵上.

而且我文章中多处出现了" 应该 尽量 通常 可以"等词汇
而几乎没有 "一定 必须 非这样不可"的字眼.

同时,我发现你又把话题引到另外的范畴了

真拿你没办法 呵呵 无奈啊.

我从来没有说过你的观点是错的(而且我很明确的说过:你的观点是正确的)
你的观点没错.一直都很正确,只是和我讨论的问题没什么关系而已.

我也不了解 应该不一样吧
可能更想 模板语言 jsp  或者 gwt那种吧.

期待有人指点.

标题显的有点儿大，不过lz的意思还是明白的，好像有点儿带有网络交互功能的Java Web Start的意思。