我认为服务器在帮我写socket我不喜欢写这个东西 我得自己去定义语法和语义
我可以把bs的东西作的像cs 我在客户端指定服务器执行什么动作通过xml返回结果
可我还是使用浏览器
因为我可以完全(而且是很方便的)控制浏览器的所有东西
我会注明"只支持ie5.5以上的版本"因为我觉得ie的用户足够我用了 别的用户我不需要
这样的话我不会去考虑版本问题了
我的代码都很简单 一个动作只有几行或者几十行代码 对于复杂的运算我一般写dll或者js文件
而且 只要有个记事本就行了
我可以把bs的东西作的像cs 我在客户端指定服务器执行什么动作通过xml返回结果
可我还是使用浏览器
因为我可以完全(而且是很方便的)控制浏览器的所有东西
我会注明"只支持ie5.5以上的版本"因为我觉得ie的用户足够我用了 别的用户我不需要
这样的话我不会去考虑版本问题了
我的代码都很简单 一个动作只有几行或者几十行代码 对于复杂的运算我一般写dll或者js文件
而且 只要有个记事本就行了
c/s内部网用得更多！多种协议，同样它可以实现http协议，一般专用！
个人而言，我比较喜欢b/s,客户端只需要一个brower!挺省事的！
:)
看看Web设计人员为什么而对CSS欢呼雀跃？为了能绝对定位一个Label，一个图片！这在Client里简直是易如反掌之事！当我们想把网页里的几块东西摆齐的时候，看看我们用了多少个Table？当我们想有一个圆边框的Table的时候看看我们费了多大劲！打开sina.com.cn的源码，看一看一个简简单单的结构在这里要写多少行代码，要用多复杂的结构。而这一切的一切(包括很多其它没说到的)在传统Client中实现起来简直不值一提。
----------------------------------------------------------------------------呵呵，c/s是用图形开发界面的，难道b/s开发人员就都用写字板啊？我们一样有图形开发界面啊。再说要是大家都用写字板写界面，那b/s恐怕也要比c/s效率来的高的多。
再说sina.com.cn关b/s什么事？既然要全面的讨论，还有“很多其它没说到的”干吗不一块说了？
1、不一定要写socket，用Java的RMI可以非常方便的完成。即便是socket，我想处理多版本的浏览器一定更烦人(准确的说是更无聊！)。而且你也可以控制你的client里的所有东西(如果真的需要，我想说的是八成没有这个必要)。注明类似"只支持ie5.5以上的版本"的话是个好办法，但是对于不太固定的用户群这至少算不上完美的办法。也许你的大多都代码都很简单，但是用CS也不会更复杂，常常反而会更简单。写java也只需要一个记事本，当然也有好的IDE，比如JBuilder.2 wanghr100(灰豆宝宝.net)，欢迎发言，哪怕是反对我的。但是也请看清我的发言再说话，否则会浪费大家的时间。“所谓3-tier结构”不是BS的专利，我已经说了两遍了(你当然也可以反对，但请说出理由)。而你的前两段内容都象个自说自话的商业介绍，论点没有什么根据。比如“用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本”“显然B/S结构应用程序相对于传统的C/S结构应用程序将是巨大的进步”云云看得我有点摸不到头脑。我没猜错的话，这些都是用来骗外行的吧？你的关于“C/S 与 B/S 区别”我也是不大理解。比如说联众的client就是建立在广域网之上的CS结构，而不是很好吗？你说(抄)的话（恕我直言），错误百出：
“B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上. 比C/S有更高的要求 B/S结构的程序架构是发展的趋势, 从MS的.Net系列的BizTalk 2000 Exchange 2000等, 全面支持网络的构件搭建的系统. SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟.”
我认为无论是安全性还是访问效率，CS都要高于BS，如果你理解你自己在说什么，请说明一下你的根据是什么？
“C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高”，
这句话真叫我哭笑不得，Socket最早出现在UNIX上，在UNIX与LINUX上的SC结构程序成千上万，说CS多是window平台上完全没有根据，表现方法有现更是“不知所指”，我敢拍着胸脯说，你用浏览器表现出来的界面与效果我全能用client表现出来！但是我用client表现出来的你敢说都能用browser表现出来吗？不说别的就说你能把浏览器设为不规则形状窗口吗(比如妥圆形)？关于“８．信息流不同 ”，我没看懂。3 同意BS结构也（“也”的意思你明白吧）有大量好的工具。关于“要是大家都用写字板写界面，那b/s恐怕也要比c/s效率来的高的多”，虽然完全不可比，但是“高的多”的“多”字用得还是过于牵强了吧？对于非常单简的界面写起来（用记事本）HTML比VC要快个十来陪，比VB用可视化开发工具也不会慢。但那是因为HTML只能实现非常简单的界面，复杂的你试试，不是做不了就是非常（或非常非常非常非常）麻烦（如菜单）。这就好比在说“傻瓜相机比专业相机要好，因为操作起来比专业相机方便多了”，这话也不一定就错了，好比对我这样的摄影门外汉傻瓜就是比专业好（拍出来起码能看），可是你要是对专业的这么说……还不笑死人家？关于“既然要全面的讨论，还有“很多其它没说到的”干吗不一块说了？”，反过来说更方便：除了直接用标签标出来的东西（比如text，button,title）之外，还有什么东西能方方便便的做出来？比如一个树控件，一个菜单，不是不能做，但很烦（不是吗？）。说到全面性，你为什么不说说传输量，浏览器版本问题与安全性？
关于“要是大家都用写字板写界面，那b/s恐怕也要比c/s效率来的高的多”，虽然完全不可比，但是“高的多”的“多”字用得还是过于牵强了吧？
-------------------------------------------------------------------
不错，太牵强了，什么叫“多”，这是相对而言的。我的意思是：b/s的b端程序员大多非常熟悉怎么在文本编辑器中修改页面外观，而c/s的程序员就未必了。-------------------------------------------------------------------
但那是因为HTML只能实现非常简单的界面，复杂的你试试，不是做不了就是非常（或非常非常非常非常）麻烦（如菜单）。
-------------------------------------------------------------------
我基本不做非常简单的界面呵呵。是否麻烦要也要看人看工具看方法的，这里你和我上面一样的牵强。-------------------------------------------------------------------
这就好比在说“傻瓜相机比专业相机要好，因为操作起来比专业相机方便多了”，这话也不一定就错了，好比对我这样的摄影门外汉傻瓜就是比专业好（拍出来起码能看），可是你要是对专业的这么说……还不笑死人家？
-------------------------------------------------------------------
呵呵本来不该在js论坛讨论摄影的，不过既然相机和开发模式已经被你拿来相类比了我也不妨告诉你“傻瓜相机比专业相机要好，因为操作起来比专业相机方便多了”这样的话也不见得错，翻开专业摄影师的摄影包在里面发现个把傻瓜备用相机都很正常，因为小巧方便，抓拍的时候比机械相机有优势。全国摄影家协会会员，四川摄影协会理事董尧尧跟我说，他老婆（也算半专业吧？）的几幅获奖作品都是拿傻瓜机拍的（准确的说是奥林巴斯u-2）。-------------------------------------------------------------------
关于“既然要全面的讨论，还有“很多其它没说到的”干吗不一块说了？”，反过来说更方便：除了直接用标签标出来的东西（比如text，button,title）之外，还有什么东西能方方便便的做出来？比如一个树控件，一个菜单，不是不能做，但很烦（不是吗？）。说到全面性，你为什么不说说传输量，浏览器版本问题与安全性？
-------------------------------------------------------------------
我的意思就是，你为什么不把这些拿出来谈呢？
其实切菜就是该用菜刀，削苹果就是该用水果刀，情急拼命的时候身上带什么刀就该用什么刀。哪有什么刀就一定比什么刀好呢？
当然开发一个b/s架构的软件需要很多工具的结合，很可能还不能达到c/s的效果，b/s再很多方面如：报表，安全性，（数值的精度）等方面都存在问题。在网络盛行的今日，我还是喜欢b/s的。
不管是从开发、维护等角度来看都比c/s要好，我相信以后b/s会把c/s给完全取代
这段话充分反映了搂主学习b/s开发方法而不得的郁闷心情:D
b/s开发还是很简单的,我用了快半年了,html,css,js没有你想的那么难,还而言之,其实是很简单的,要比c/s方面的语言简单的多,一通百通,用心学吧,搂主!别在这里发牢骚了,有你发牢骚这份时间,也许你又掌握了一个event,一个method,一个标签........
关于：“-------------------------------------------------------------------
但那是因为HTML只能实现非常简单的界面，复杂的你试试，不是做不了就是非常（或非常非常非常非常）麻烦（如菜单）。
-------------------------------------------------------------------
我基本不做非常简单的界面呵呵。是否麻烦要也要看人看工具看方法的，这里你和我上面一样的牵强。”
因为我CS做得多，感觉BS麻烦，你BS做的多感觉CS麻烦——很有道理！“-------------------------------------------------------------------
这就好比在说“傻瓜相机比专业相机要好，因为操作起来比专业相机方便多了”，这话也不一定就错了，好比对我这样的摄影门外汉傻瓜就是比专业好（拍出来起码能看），可是你要是对专业的这么说……还不笑死人家？
-------------------------------------------------------------------
呵呵本来不该在js论坛讨论摄影的，不过既然相机和开发模式已经被你拿来相类比了我也不妨告诉你“傻瓜相机比专业相机要好，因为操作起来比专业相机方便多了”这样的话也不见得错，翻开专业摄影师的摄影包在里面发现个把傻瓜备用相机都很正常，因为小巧方便，抓拍的时候比机械相机有优势。全国摄影家协会会员，四川摄影协会理事董尧尧跟我说，他老婆（也算半专业吧？）的几幅获奖作品都是拿傻瓜机拍的（准确的说是奥林巴斯u-2）。”
所以你想说：“傻瓜相机是专业人员未来选用产品的趋势，是大势所趋，而专业相机将被淘汰”，我认为HTML是“傻瓜相机”，但是要做项目还必须在您这个傻瓜相机前面加一个傻瓜相机专用专业“镜头”（要为各种光线准备不同的“镜头”，而且这种镜头发生错误也是家长便饭），而傻瓜相机后面要加装一串复杂专业的电路模块——不要以为很麻烦，因为我们已经提供了一系列专门的机器会自动帮您完成大部分装配工作——所以“傻瓜相机”是最高科技的（其实根本就是最复杂最变态的）
关于：“其实切菜就是该用菜刀，削苹果就是该用水果刀，情急拼命的时候身上带什么刀就该用什么刀。哪有什么刀就一定比什么刀好呢？”
我认为软件选型与“情急拼命”应该完全是两码子事吧？（中国的很多垃圾项目就是“情急拼命”时用“水果刀”削出来的）sw47(电褥子) ：说到一通百通你要是熟悉C或java，你一定会更深的领悟什么叫“一通百通”html,css,js都不难，而且非常之不难，这我同意，但是用起来两个字“麻烦”！就好比上面的一个关于相机的例子（自己想想还挺幽默）
所以你想说：“傻瓜相机是专业人员未来选用产品的趋势，是大势所趋，而专业相机将被淘汰”，我认为HTML是“傻瓜相机”，
--------------------------------------------------------------
看看下面的刀子理论你就知道我不是这个意思了。摄影你是真的不懂，傻瓜相机只是抓拍的时候好，拍艺术作品还是要靠专业设备。说到淘汰，你看网络淘汰了报纸吗，电视淘汰了广播吗？同样的b/s和c/s谁能淘汰谁呢？--------------------------------------------------------------
我认为软件选型与“情急拼命”应该完全是两码子事吧？
--------------------------------------------------------------
我没有说过是一回事啊。我这里只的是面对不同的情形的时候选择工具的问题，比如被项目追的喘不过气的时候，也许就放弃了效率上的考虑，要排序就先用最简单的冒泡法顶着，项目缓过气来了再写快速排序，被项目追过的人都知道。
我的原意是想讨论BS结构对于现在很多项目是否合适，尤其是对于BS的开发复杂，反琐而言。
--------------------------------------------------------------------是否烦琐要看项目本身的复杂程度和系统分析的水平而不是看是c/s还是b/s。
不过现在越来越多的软件采用b/s确实是一个趋势，其中的原因其实远不是技术上的，毕竟我们做软件不是怎么容易做怎么来的（否则现在大家都在命令行状态下了呵呵）。--------------------------------------------------------------------
就BS而言我想开发周期更快的还是CS吧？
--------------------------------------------------------------------说到开发周期，软件工程书上肯定跟你说软件生命周期是哪几个部分够成的吧？你是指哪个部分c/s比b/s快？为什么快，快多少，在软件开发周期中会带来多大的影响？对整个软件生命周期又又什么样的影响？
是否烦琐要看项目本身的复杂程度和系统分析的水平而不是看是c/s还是b/s。
----------------------------------------------------------------
我不知道你这话是不是有点逃避主题之嫌，是不是想说对于同样一个项目一个需求，CS与BS开发的复杂度是完全一样的，因此也就无需讨论这个问题？----------------------------------------------------------------
其中的原因其实远不是技术上的，毕竟我们做软件不是怎么容易做怎么来的（否则现在大家都在命令行状态下了呵呵）。
----------------------------------------------------------------
我没有说过评价好坏的标准就只是“怎么做容易”，如果你认为BS有什么方面“虽然不算最容易”，但是更高效或者能实现CS所不能实现的功能，请直接说出你的观点与理由
___________________________________________________________________
说到开发周期，软件工程书上肯定跟你说软件生命周期是哪几个部分够成的吧？你是指哪个部分c/s比b/s快？为什么快，快多少，在软件开发周期中会带来多大的影响？对整个软件生命周期又又什么样的影响？
___________________________________________________________________
你这个泡泡可吹得不小，呵呵呵呵……。我是以C比B的角度来看问题的，认为B的view与controller开发反琐（比CS而言），所以认为CS周期更快（因为简单直接（快多少这种问法不太专业吧？））。其它方面不认为有本质区别。如果你不同意，可以提出来，但请给出理由。
“为什么快，快多少，在软件开发周期中会带来多大的影响？对整个软件生命周期又又什么样的影响”必须针对特定事物来说吧？否则你告诉我硬盘比软驱快多少？（说不出就意味着硬盘不比软驱快？）
________________________________________________________________________________
当这一切都成为了习惯，当大多数功能已经成为了模块，我开始喜欢上了B/S，B/S程序如同给了你一张张的白纸，你可以任意的控制这张白纸上的任何控件~~，一只笔，一只橡皮，随意的勾勒你的程序~~，你在C/S上控制一个试验一下，恐怕没那么容易啊，B/S的表格，简直是灵活透顶~~
________________________________________________________________________________
看得我口水直流，不过，那一点在CS上不容易能不能说清楚。（旧社会时裹小脚，那些姑娘开始时也不习惯，但是后来当这一切都成为了习惯，她们也觉得还不错了）
楼主认为是几个东西?
[email protected]我会极力响应;显然楼主还没有表达出要呼吁的观点
---------------------------------------------------------------------------------
难道楼主认为c/s就是java?虽然完全不可比，但是“高的多”的“多”字用得还是过于牵强了吧？对于非常单简的界面写起来（用记事本）HTML比VC要快个十来陪，比VB用可视化开发工具也不会慢。但那是因为HTML只能实现非常简单的界面，复杂的你试试，不是做不了就是非常（或非常非常非常非常）麻烦（如菜单）。
-----------------------------------
你认为菜单很复杂吗 我用1分钟 你呢?
还有 到现在我还没有预见做不了的"复杂"界面 你有吗 说出来 大伙儿瞧瞧你用浏览器表现出来的界面与效果我全能用client表现出来！但是我用client表现出来的你敢说都能用browser表现出来吗？不说别的就说你能把浏览器设为不规则形状窗口吗(比如妥圆形)？
_________________________
如果你会作控件 你就该把你的话反着说
就说椭圆形的界面吧,说句实话我是不会做,用java,vb,vc都不会,你会哪一个?
调用api不是你的本事，我也能掉。如果用图片的话倒是很轻松。
如果要做椭圆形界面的话，很容易：把浏览器隐藏了，把你的界面掉出来就行了，你要乐意，帮我封装一下，不乐意我就自己动手
顺便提一下，我对使用非IE的用户群不屑一顾，有了大海不稀罕水塘看看Web设计人员为什么而对CSS欢呼雀跃？为了能绝对定位一个Label，一个图片！这在Client里简直是易如反掌之事！
————————————————————
是吗 要实现{ filter: BlendTrans (Duratio=5)}效果恐怕得继承Thread类吧 即使继承Thread也不一定能行，你要能做出来 拿出来让大伙儿看看
顺便说一下css只是HTMl也面的一个属性而已，用起来不会比setColor（new Color（...）)什么的"麻烦"多少
就JS来说:
你又能用什么不"麻烦"的方法实现下面的功能?
myFrom.userName.onchange=new function(){return checkUserName();}总之 B/S C/S是死的 人是活的
脑子好的话 别人要花很多时间来做的"麻烦"事,也许就是1分钟的事
的事情。
一个软件做好还要让客户设置这个设置那个。那这个软件能生存多久？很显然，作为客户
他们需要的是简单直接，更新快且直接的东西。难道每次修改都要给别人下载或者安装什么
的？如果我是客户那我绝对不想用它。当然游戏除外。
对于针对少数人使用的软件－－我想只要使用恰当B/S,C/S都有他的好处。你说B/S环境设
置麻烦，那是你作一个程序员不合格。麻烦了你却方便了客户，这不是软件开发的大方向吗？
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
你说：“为什么快，快多少，在软件开发周期中会带来多大的影响？对整个软件生命周期又又什么样的影响”必须针对特定事物来说吧？否则你告诉我硬盘比软驱快多少？（说不出就意味着硬盘不比软驱快？
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
“为什么快，快多少，在软件开发周期中会带来多大的影响？对整个软件生命周期又又什么样的影响”
必须针对特定事物来说吧？否则你告诉我硬盘比软驱快多少？（说不出就意味着硬盘不比软驱快？）
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 我不知道你学软件工程的时候是否逃课。编码的情况我想在软件工程里面是最微不足道的了。而直接影响软件周期的不就是需求分析、测试和软件的维护吗？
很直接，如果是B/S，只需要商户修改掉错误，用户能马上受益，这样的优势难道还不够诱惑吗？
我不像针对这样的傻问题多说，B/S,C/S都有他们自己的好处，关键看怎样使用。
html,css,js
楼主认为是几个东西?
--------------------------
楼主也说不清是几个东西，但至少比3个多（我认为），又什么都不是。-------------------------
难道楼主认为c/s就是java?
-------------------------
cs不是java，但是总要用一用语言实现，你见过不用任何一种语言实现的CS（哪怕是BS）项目吗？
---------------------------------
你认为菜单很复杂吗 我用1分钟 你呢?
还有 到现在我还没有预见做不了的"复杂"界面 你有吗 说出来 大伙儿瞧瞧
_________________________________
我很佩服你的技术，先说清这个，因为一分钟做一个菜单真的很快，而且没有做不出的界面也很让我佩服。但你比较过做同样的东西，BS、CS两者的不同吗？而且，BS，CS不是单指界面开发复杂度不同，而是指的其通过在只有静态HTML功能的前后补东补西出来的一大套东西(各种所谓技术)，不过就是为了做成一个client而已（不是吗？）----------------------------------
就说椭圆形的界面吧,说句实话我是不会做,用java,vb,vc都不会,你会哪一个?
----------------------------------
VB我见过书上的例子，VC我亲手做过几个（你喜欢可以给你发源吗）。至于你的没有“预见到”我猜多半是因为在您“预见”的时候，多半B已经根深地固的在你的头脑中了__________________________________________________________________
就说椭圆形的界面吧,说句实话我是不会做,用java,vb,vc都不会,你会哪一个?
调用api不是你的本事，我也能掉。如果用图片的话倒是很轻松。
如果要做椭圆形界面的话，很容易：把浏览器隐藏了，把你的界面掉出来就行了，你要乐意，帮我封装一下，不乐意我就自己动手
顺便提一下，我对使用非IE的用户群不屑一顾，有了大海不稀罕水塘
__________________________________________________________________
这个我还真不知道怎么做（隐藏浏览器），以后有机会也教教我们这会小字辈吧？不过我还是不大相信，希望给出源码。对“使用非IE的用户群不屑一顾”，无所谓，随你高兴吧，只要你的用户都用IE就没问题-------------------------------------------------
我不知道你学软件工程的时候是否逃课。编码的情况我想在软件工程里面是最微不足道的了。而直接影响软件周期的不就是需求分析、测试和软件的维护吗？
很直接，如果是B/S，只需要商户修改掉错误，用户能马上受益，这样的优势难道还不够诱惑吗？
我不像针对这样的傻问题多说，B/S,C/S都有他们自己的好处，关键看怎样使用。
-------------------------------------------------
我的软件工程只考了60分，哈哈哈。你说编码是最微不足道的，我同意。但是第一、那是在有详细设计文档的时候，国内的话，没听说哪个地方这样做了（做也就是做做样子罢了）。第二BS为设计管理项目都带来了问题，如分层太多，技术太杂，所以设计所需顾虑问题太多，人员使用不灵活，测试量大（为不同B都要做测试，当然你的客户只用IE而且只用一个版本的，（他们都是你孙子？）所以这一点你不用担心。：））
商户能马上修改错误，IE却未必行，不是吗？如果每次使用C的时候都是从S临时下载，那C中的错误修正也可以立刻表现出来，看来也很诱惑人了（美女？），呵呵____________________________________
我不像针对这样的傻问题多说，B/S,C/S都有他们自己的好处，关键看怎样使用。
____________________________________
我看只要能学道东西，而且是针对减少项目成本的讨论，傻也傻得可爱呢。而且同意在某些情况下BS要优于CS。
是不是想说对于同样一个项目一个需求，CS与BS开发的复杂度是完全一样的
-----------------------------------------------------------------------------
我想说的是，我们选择b/s还是c/s往往主要不是开发复杂程度上的考虑。
>>我没有说过评价好坏的标准就只是“怎么做容易”......呵呵你基本上是说过了的，你忘了：“尤其是对于BS的开发复杂，反琐而言。就BS而言我想开发周期更快的还是CS吧？”，换言之就是，怎么快怎么好，不是吗？
>>如果你认为BS有什么方面“虽然不算最容易”，但是更高效或者能实现CS所不能实现的功能，请直接说出你的观点与理由
比如我这两年来做过的所有的项目，如果用c/s的话就都不用做了呵呵，因为没有参加投标的资格。这里牵扯到了我的另一层观点，客户需要的是b/s还是c/s，对我们的选型才有真正的决定意义。我们来看看c/s的致命弱点：要在没个客户端安装一个client。这对于早期的客户是没问题的，但是现在我们的客户要做的事情很多，从多个供应商那里购买不同的软件，你想要是每个供应商要给他安装一个client他还要不要工作了？用b/s就没有这个顾虑了，只要一个client而且他那里已经早就装好了，相互之间也不存在冲突，重装系统也不用特地一个个client的重装上去。所以我不否定c/s有他自己的生存发展空间，可是b/s这些年的发展大家有目共睹，这并不是什么开发难易程度上的因素在影响。>>我是以C比B的角度来看问题的，认为B的view与controller开发反琐（比CS而言），所以认为CS周期更快（因为简单直接（快多少这种问法不太专业吧？））
view的问题我前面说过了，c/s有IDE，b/s也有，c/s可以拖放可以wysiwyg,b/s也可以，c/s有api，b/s也有代码库，要说什么比什么快，还是要看谁来做。
>>“为什么快，快多少，在软件开发周期中会带来多大的影响？对整个软件生命周期又又什么样的影响”必须针对特定事物来说吧？否则你告诉我硬盘比软驱快多少？（说不出就意味着硬盘不比软驱快？）
请看你的原话：“就BS而言我想开发周期更快的还是CS吧？”，那么你是针对什么的特定事物提出这个想法的？
错别字，一大片勘误：1）不好意思，我们有读完
==>
不好意思，我们没有读完
2）当然想symantic的LiveUpdate等，实时更新技术
==>
当然，象symantic的LiveUpdate等实时更新技术3）不过没办法，现世世界就是这样
==>
不过没办法，现实世界就是这样4）是他更结识
==>
使他更结实
>楼主认为是几个东西?
>--------------------------
>楼主也说不清是几个东西，但至少比3个多（我认为），又什么都不是。
我认为是一个东西,跟用java调class一样.说起复杂，远没有java或者c得类复杂-------------------------
>--难道楼主认为c/s就是java?
>---------------------------
>--cs不是java，但是总要用一用语言实现，你见过不用任何一种语言实现的CS（哪怕是BS）项目吗？
那楼主就不应该用java在网络上的优势来否认c/s体系中使用socket的复杂性>--------------------------------
>你认为菜单很复杂吗 我用1分钟 你呢?
>还有 到现在我还没有预见做不了的"复杂"界面 你有吗 说出来 大伙儿瞧瞧
_________________________________
>我很佩服你的技术，先说清这个，因为一分钟做一个菜单真的很快，而且没有做不出的界面也很让
>我佩服。但你比较过做同样的东西，BS、CS两者的不同吗？而且，BS，CS不是单指界面开发复杂度>不同，而是指的其通过在只有静态HTML功能的前后补东补西出来的一大套东西(各种所谓技术)，不>过就是为了做成一个client而已（不是吗？）
在我脑子里HTML不是一个静态的东西 而是一个“现成”的，“所有浏览器都支持”的某个协议的表示方法。对于同一个东西，bs,cs最大的区别是，bs不用解析服务器上传过来的数据。
----------------------------------
>就说椭圆形的界面吧,说句实话我是不会做,用java,vb,vc都不会,你会哪一个?
>----------------------------------
>VB我见过书上的例子，VC我亲手做过几个（你喜欢可以给你发源吗）。
你要是没有调用api就帖出来让大家看看__________________________________________________________________
>就说椭圆形的界面吧,说句实话我是不会做,用java,vb,vc都不会,你会哪一个?
>调用api不是你的本事，我也能掉。如果用图片的话倒是很轻松。
>如果要做椭圆形界面的话，很容易：把浏览器隐藏了，把你的界面掉出来就行了，你要乐意，帮我
>封装一下，不乐意我就自己动手
>顺便提一下，我对使用非IE的用户群不屑一顾，有了大海不稀罕水塘
>__________________________________________________________________
>这个我还真不知道怎么做（隐藏浏览器），以后有机会也教教我们这会小字辈吧？不过我还是不大
>相信，希望给出源码。对“使用非IE的用户群不屑一顾”，无所谓，随你高兴吧，只要你的用户都
>用IE就没问题
1.隐藏浏览器：<onbody onload="window.moveTo(6000,6000);showLayer(此函数显示一个不规则形状图片作为背景的透明Layer)">
2.我敢保证我的用户用的都是IE5.0以上版本的浏览器，我敢保证至少在天津所有的（只要是国家发工资的）机关事业单位用的都是IE5.0以上版本
<body onload="window.moveTo(6000,6000);showLayer(此函数显示一个不规则形状图片作为背景的透明Layer)">
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------------------------------------------------------------------------
是不是想说对于同样一个项目一个需求，CS与BS开发的复杂度是完全一样的
-----------------------------------------------------------------------------
我想说的是，我们选择b/s还是c/s往往主要不是开发复杂程度上的考虑。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
回应观点在所引同一处最下面：“你说编码是最微不足道的，我同意。但是第一、那是在有详细设计文档的时候，国内的话，没听说哪个地方这样做了（做也就是做做样子罢了）。第二BS为设计管理项目都带来了问题，如分层太多，技术太杂，所以设计所需顾虑问题太多，人员使用不灵活，测试量大（为不同B都要做测试，当然你的客户只用IE而且只用一个版本的”说明了这种比较不是片面的。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>我没有说过评价好坏的标准就只是“怎么做容易”......呵呵你基本上是说过了的，你忘了：“尤其是对于BS的开发复杂，反琐而言。就BS而言我想开发周期更快的还是CS吧？”，换言之就是，怎么快怎么好，不是吗？
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
您所引我的话处的上一贴：就是您自已的话“
--------------------------------------------------------------
我认为软件选型与“情急拼命”应该完全是两码子事吧？
--------------------------------------------------------------
我没有说过是一回事啊。我这里只的是面对不同的情形的时候选择工具的问题，比如被项目追的喘不过气的时候，也许就放弃了效率上的考虑，要排序就先用最简单的冒泡法顶着，项目缓过气来了再写快速排序，被项目追过的人都知道。
”我的话是回应您对开发周期的考虑（指所谓“比如被项目追的喘不过气的时候”），假设必然是在“其它方面相同条件”之下。>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
如果你认为BS有什么方面“虽然不算最容易”，但是更高效或者能实现CS所不能实现的功能，请直接说出你的观点与理由
比如我这两年来做过的所有的项目，如果用c/s的话就都不用做了呵呵，因为没有参加投标的资格。这里牵扯到了我的另一层观点，客户需要的是b/s还是c/s，对我们的选型才有真正的决定意义。我们来看看c/s的致命弱点：要在没个客户端安装一个client。这对于早期的客户是没问题的，但是现在我们的客户要做的事情很多，从多个供应商那里购买不同的软件，你想要是每个供应商要给他安装一个client他还要不要工作了？用b/s就没有这个顾虑了，只要一个client而且他那里已经早就装好了，相互之间也不存在冲突，重装系统也不用特地一个个client的重装上去。所以我不否定c/s有他自己的生存发展空间，可是b/s这些年的发展大家有目共睹，这并不是什么开发难易程度上的因素在影响。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
回答就在我的问题（第二点）中：“人们说CS中client更新不方便。以前已有人说过用自动更新机制，如每次连接时check版本，如需要当时下载。这当然是一个好办法。我想说的是还有一个好办法，不知道大家有没有注意到Pet Store？里面check order的client(就是CS结构)是用时临时从Server端下载的(通过在浏览器里点击一个连接就自动下载运行了)(比起web来却只下载一次)，而且调用的主要模块是远程RMI Server里的东西。我想可能会是以后n层CS的典型用法，完全不存在更新不便的问题，而且不受浏览器版本影响。”另注：“本质上就是跳过了“http及前后的东西，而且不需要安装！(希望不要再让我重复了，累死了都)”>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
我是以C比B的角度来看问题的，认为B的view与controller开发反琐（比CS而言），所以认为CS周期更快（因为简单直接（快多少这种问法不太专业吧？））
view的问题我前面说过了，c/s有IDE，b/s也有，c/s可以拖放可以wysiwyg,b/s也可以，c/s有api，b/s也有代码库，要说什么比什么快，还是要看谁来做。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
看看J2EE典型BS结构：script+HTML+CSS->servlet（做control）->JSP(做view)->java Bean->|(EJB)
再看看J2EE典型CS结构 client(java swing)->|(EJB)
比一比：CS在EJB前一个JBuilder只用java就OK了。script+HTML+CSS+servlet+JSP+javaBean最后出的也是一个view，您用得什么IDE全“自动”完成了？也许你想说，client也不是全自动完成的，我同意！但是这说起来就不得不说那个手动完成起来要好一些了吧？
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
“为什么快，快多少，在软件开发周期中会带来多大的影响？对整个软件生命周期又又什么样的影响”必须针对特定事物来说吧？否则你告诉我硬盘比软驱快多少？（说不出就意味着硬盘不比软驱快？）
请看你的原话：“就BS而言我想开发周期更快的还是CS吧？”，那么你是针对什么的特定事物提出这个想法的？
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
我说的每一句话都在（试图）证明“周期更快的还是CS”。就事实来说，请参考大量CSDN上的发言，其中一个如下：
回复人： feiyuegaoshan(飞跃) ( ) 信誉：105 2003-06-24 00:18:00 得分:0
to:runer(今天真冷)我是以自己的经验来说的。
希望对大家有用。我们目前刚开发完一个很大的系统（数据表就有60多个，有6个人月），是纯粹的b/s结构。
网页设计真是占用了大部分时间，而且还不让人很满意。如果用Java的application做client，有2个人月就差不多了。但你知道Java的application变成applet需要多少时间吗？几分钟就可以了。而这种变化带来的本质飞跃就是由C/S变成了B/S。却同时拥有了两者所有的优点。你管这种变化叫“中庸之道”吗？---------------------------------------------
此外有人说我学BS而不得其法，我想这话有道理，在BS方面我是个新手。学BS的时候感觉很烦也是真的，因为明明很简单的事情无缘无故弄得很复杂（而不是说因为博大深奥难以理解）。但是我想我就是学懂了它是什么才来讨论的，至少javascript,HTML,CSS,servlet，JSP，java Bean我都懂，我想这样应该不算是无的放矢吧？
这一段原来并非对我的回应（回应的是 hahacc(出師無名)），所以我也没有回应这段话。既然你现在拿它来回应我，那我也谈谈我的看法：
* 说编码是“微不足道的”我誓死不同意。我认为编码质量和系统分析水平的重要性不相上下，工作量方面软件工程的书里也早有统计数字。
* 说国内的开发都没有详细设计文档或者仅仅做做样子也完全不同意，不知道你是做过什么样的调查统计得出的结论？我没有听说过哪个成功的软件项目（蒙钱项目不算）没有完善的设计文档。
* B/S为设计管理项目都带来的问题决不会比面向对象带来的问题多，任何新事物都有个熟悉普及的过程，在一个成熟的b/s开发团队中，你所提的种种问题早就不是问题了（怎么解决的？合理分工咯。一个真正复杂的项目当然不是靠一个全才天材来完成的）。
>>我的话是回应您对开发周期的考虑（指所谓“比如被项目追的喘不过气的时候”），假设必然是在“其它方面相同条件”之下。
这个话题已经越来越不知所云了，我真的不知道在这个方面你的观点是什么？
>>就BS而言我想开发周期更快的还是CS吧？
>>我没有说过评价好坏的标准就只是“怎么做容易”
两个观点你全占了呵呵。简单的说，你到底是否认为c/s开发比b/s的优势很大程度上体现在“容易做”或者“做起来快”上面呢？这是我们的分歧之一所在。>>回答就在我的问题（第二点）中：“人们说CS中client更新不方便......
我也不希望看到你重复的这么累的，要是你仔细看了我说的话你就不用如此了，因为我回帖之前确实仔细的回顾了你以上的观点的，但是客户讨厌的并不只是“更新不方便”，而是安装一个客户端，不管更新不更新，都够讨厌的。如果我们现在想访问这个论坛讨论b/s好还是c/s好之前居然还要去特地下载一个csdn论坛客户端，你有什么感想？我现在看到托盘图表栏里面同时摆着 QQ, MSN, YahooMessenger 三个client，我都觉得够难受了，只是因为实在没有办法才只有忍受。>>比一比：CS在EJB前一个JBuilder只用java就OK了。
不管你承认与否，你在说的其实就是“评价好坏的标准就只是‘怎么做容易’”了。
多层控制带来的是多方面的好处，b/s也可以简单的:JSP(做view)->java Bean->|(EJB)，事实上这是许多简单项目采用的模式。额外的层次是为了获得额外的灵活性和交互性。此外你的两个“典型结构”都不见得很典型。client(java swing)->|(EJB) 这样的结构可以做出能与 DHTML->servlet(control)->JSP/servlet(view)->java Bean->|(EJB) 一样复杂和灵活的系统吗？我非常怀疑。顺便说一下，script+HTML+CSS我们一般直接叫DHTML，因为在动态html页面中向来都是综合使用的。你很刻意的把他分成三样东西，当然也没错，正如我们可以把ejb分成很多很多样东西，有意义吗？
>>我说的每一句话都在（试图）证明“周期更快的还是CS”。
ok,那么我在试图说出来的观点是：b/s未必象你想象的那么慢，而选择b/s还是c/s也不该只考虑开发周期。
此外有人说我学BS而不得其法，我想这话有道理，在BS方面我是个新手。学BS的时候感觉很烦也是真的，因为明明很简单的事情无缘无故弄得很复杂（而不是说因为博大深奥难以理解）。但是我想我就是学懂了它是什么才来讨论的，至少javascript,HTML,CSS,servlet，JSP，java Bean我都懂，我想这样应该不算是无的放矢吧？
--------------------------------------------------------------------------明明很简单的事情无缘无故弄得很复杂，往往是因为使用了错误的方法（明明可以sort()的时候你是否自己写了冒泡排序法？），重复的造了轮子（你是否照着算法手册自己做了MD5函数？），或者轮子还没出现（我们很多人在这个论坛上都在努力的造新的轮子并免费的发布出来，浏览器技术本身也在进步）。当然有的时候确实有“无缘无故弄得很复杂”的情形，想想在“无缘无故弄得很复杂”方面有什么赶得上OO呢？
当然有的时候确实有“无缘无故弄得很复杂”的情形，想想在“无缘无故弄得很复杂”方面有什么赶得上OO呢？
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
我想针对这话反驳一下下，但是不用打出来了，因为我想说什么你一定猜得到。好了，求同存异，是结贴的时候了。
* 最终一个软的好坏还是看coding出的代码，所以你说编码重要我理解。但是（按软件工程的理论）在coding之前有需求分析、概要设计、详细设计；在coding之后有白黑盒测试（你一定知道现在还有质量控制一说（在项目过程中体现））。而到了详细设计基本上对于每个小模块（细到函数）的接口参数个数与类型内部结构，算法与流程都订好了，所以coding是“微不足道的”——可以交给高中生去做。如果coding做不好，那可能是程序员的工作态度问题而不是技术水平问题。而且，有测试来做最后保证不会有什么问题。所以coding的时间短，人员也许不少但是不需要高技术人员（或说高成本人员），总体花费也少。
* 我也在很多家公司了解过他们的设计文档情况，没有详细到我上面说得那样的公司，绝大部分是不做全面的详设的。而且在国内也真的很少听过什么“成功的软件项目”，九成儿不成功！（真不知道你是做什么行业的，连这个都不知道）
关于OO与BS
OO是伟大的革新，合理的使用OO能带来很多好处。不知道OO的哪里让你产生了不满？BS与OO的不同就在于OO是针对软件危机研究出来的技术与概念，是为软件重用与划分而研究出来的。而BS是什么？是搭建在静态HTML之上的，以补丁方式产生动态效果的技术。同时它也是浏览器大战的产物，留下了乱七八糟一大堆非技术因素的东西。关于“合理分工”
通过分工解决BS的长长的技术战线确实是有效的办法（也是唯一的办法）。但是不是完美的办法，你是可以分工没错，但是在多个项目同时进行时，人员调配自然会更困难一些，比如做JavaScript的闲出来了一些，但是没有办法帮助忙得快要死了的做JSP的（这只是一个比方），要花更多的钱（加班费与误工费）。而这种分工的必要性在哪里呢？CS也分工，分工的必要性一针见血。BS呢，因为有很多层？为什么有很多层，还是老问题，因为HTML不支持动态，所以我们要模拟；因为要在浏览器大战后的一片狼藉之上构筑你的项目——从技术本身讲这些本来是可以避免的关于“开发周期”
开发周期长短是应该被考虑在内的因素，但又不是唯一的因素。所以“评价好坏的标准就"只"是怎么做容易”是片面的。但说“怎么做容易是评价好坏的标准之一”是正确的，我不认为我说了自相矛盾的话。（而是你没有分清点与面的关系吧？）关于“更新不方便”
看来是我的责任，还没有说得足够明白。让我说一下pet store中的CS的client是如何表现出来的。你（用户）打开浏览器（对你没看错，是browser），然后点击一个链接。之后全是自动无需人为干预，出现一个下载进度条，自动下载client（一般的client有几百KB不等，通常只是几个类与几个桩），自动运行。所以不需要安装，不会有什么比用browser麻烦的地方。当然这个client是有沙箱的，通常不能操作本地文件。开始下载时会慢一点，但是运行起来很快因为重复传数据少很多而且可以（也是通常）传二进制信息。不久的将来这些临时下载的class会被置于tmp目录中作为缓冲，下次下载的时候可能根本不需要什么时间（除非server的class被更新过，那样会重新下载相应类）。这一次相信解释的足够清楚了。我们这个论坛用BS很好，但是要是让你当个银行职员一天八小时不停填form然后submit，你就知道什么才叫真正的“都够讨厌的”。关于DHTML与多层
你叫“DHTML”，好，我很喜欢，以后我也这么叫。不过不管叫什么其内容的复杂度都不会随其改变。
看看你的话：“client(java swing)->|(EJB) 这样的结构可以做出能与 DHTML->servlet(control)->JSP/servlet(view)->java Bean->|(EJB) 一样复杂和灵活的系统吗？我非常怀疑。”
我一直在等你说这么精典的话，问题的关键也就在这里。CS要做灵活复杂的系统也要分层要做成MVC。但是做得再复杂也还是一个java。可能会用到很多类，但是其内容是必不可少的，其它的全是统一的，统一的语法语句使用方式。而且这种分层是技术上的，而不是为迁就HTML而做的胶合层。（这就是我的原意）再看看“client->|(EJB)”，业务逻辑在EJB中，不在JSP与servlet或是bean中，那为什么要用JSP,servlet与bean？因为要适应HTML（说白了就这么一句话）。关于EJB有很多种
有多种EJB:session(又分state 与 stateless),message,entity(又分BMP与CMP)，那倒是没有错。可是他们的分别是纯功能上的，因此他们继承不同的类。但是如果要你在做不同的EJB的时候用不同的语法你会怎么想?比如session Bean中的循环必须用while(expr)，entity Bean中的循环必须用for(;;)，message中的循环必须用do{}while(expr)，client中的循环必须用“气死你(expr){}”——你会不会认为很奇怪？有必要的分类与没必要分类硬分类之间还是很大不同的吧?(至少大家越说越明白了)
本来是想罢笔，因为该说的也说得差不多了，想来能听到的也差不多都听到了。在所有人之中想只有同一种观点本身是不可能的，通过讨论把问题说清楚，大家交流一下想必都有提高。但是又看了一看，突忽然觉得现在正是矛盾突显出来的时候，还是再说两句吧：关于 编码是不是“微不足道的”
* 最终一个软的好坏还是看coding出的代码，所以你说编码重要我理解。但是（按软件工程的理论）在coding之前有需求分析、概要设计、详细设计；在coding之后有白黑盒测试（你一定知道现在还有质量控制一说（在项目过程中体现））。而到了详细设计基本上对于每个小模块（细到函数）的接口参数个数与类型内部结构，算法与流程都订好了，所以coding是“微不足道的”——可以交给高中生去做。如果coding做不好，那可能是程序员的工作态度问题而不是技术水平问题。而且，有测试来做最后保证不会有什么问题。所以coding的时间短，人员也许不少但是不需要高技术人员（或说高成本人员），总体花费也少。
* 我也在很多家公司了解过他们的设计文档情况，没有详细到我上面说得那样的公司，绝大部分是不做全面的详设的。而且在国内也真的很少听过什么“成功的软件项目”，九成儿不成功！（真不知道你是做什么行业的，连这个都不知道）
关于OO与BS
OO是伟大的革新，合理的使用OO能带来很多好处。不知道OO的哪里让你产生了不满？BS与OO的不同就在于OO是针对软件危机研究出来的技术与概念，是为软件重用与划分而研究出来的。而BS是什么？是搭建在静态HTML之上的，以补丁方式产生动态效果的技术。同时它也是浏览器大战的产物，留下了乱七八糟一大堆非技术因素的东西。关于“合理分工”
通过分工解决BS的长长的技术战线确实是有效的办法（也是唯一的办法）。但是不是完美的办法，你是可以分工没错，但是在多个项目同时进行时，人员调配自然会更困难一些，比如做JavaScript的闲出来了一些，但是没有办法帮助忙得快要死了的做JSP的（这只是一个比方），要花更多的钱（加班费与误工费）。而这种分工的必要性在哪里呢？CS也分工，分工的必要性一针见血。BS呢，因为有很多层？为什么有很多层，还是老问题，因为HTML不支持动态，所以我们要模拟；因为要在浏览器大战后的一片狼藉之上构筑你的项目——从技术本身讲这些本来是可以避免的关于“开发周期”
开发周期长短是应该被考虑在内的因素，但又不是唯一的因素。所以“评价好坏的标准就"只"是怎么做容易”是片面的。但说“怎么做容易是评价好坏的标准之一”是正确的，我不认为我说了自相矛盾的话。（而是你没有分清点与面的关系吧？）关于“更新不方便”
看来是我的责任，还没有说得足够明白。让我说一下pet store中的CS的client是如何表现出来的。你（用户）打开浏览器（对你没看错，是browser），然后点击一个链接。之后全是自动无需人为干预，出现一个下载进度条，自动下载client（一般的client有几百KB不等，通常只是几个类与几个桩），自动运行。所以不需要安装，不会有什么比用browser麻烦的地方。当然这个client是有沙箱的，通常不能操作本地文件。开始下载时会慢一点，但是运行起来很快因为重复传数据少很多而且可以（也是通常）传二进制信息。不久的将来这些临时下载的class会被置于tmp目录中作为缓冲，下次下载的时候可能根本不需要什么时间（除非server的class被更新过，那样会重新下载相应类）。这一次相信解释的足够清楚了。我们这个论坛用BS很好，但是要是让你当个银行职员一天八小时不停填form然后submit，你就知道什么才叫真正的“都够讨厌的”。关于DHTML与多层
你叫“DHTML”，好，我很喜欢，以后我也这么叫。不过不管叫什么其内容的复杂度都不会随其改变。
看看你的话：“client(java swing)->|(EJB) 这样的结构可以做出能与 DHTML->servlet(control)->JSP/servlet(view)->java Bean->|(EJB) 一样复杂和灵活的系统吗？我非常怀疑。”
我一直在等你说这么精典的话，问题的关键也就在这里。CS要做灵活复杂的系统也要分层要做成MVC。但是做得再复杂也还是一个java。可能会用到很多类，但是其内容是必不可少的，其它的全是统一的，统一的语法语句使用方式。而且这种分层是技术上的，而不是为迁就HTML而做的胶合层。（这就是我的原意）再看看“client->|(EJB)”，业务逻辑在EJB中，不在JSP与servlet或是bean中，那为什么要用JSP,servlet与bean？因为要适应HTML（说白了就这么一句话）。关于EJB有很多种
有多种EJB:session(又分state 与 stateless),message,entity(又分BMP与CMP)，那倒是没有错。可是他们的分别是纯功能上的，因此他们继承不同的类。但是如果要你在做不同的EJB的时候用不同的语法你会怎么想?比如session Bean中的循环必须用while(expr)，entity Bean中的循环必须用for(;;)，message中的循环必须用do{}while(expr)，client中的循环必须用“气死你(expr){}”——你会不会认为很奇怪？有必要的分类与没必要分类硬分类之间还是很大不同的吧?(至少大家越说越明白了)
这是去年刘兴波大记者的论调了，你可以用关键字“软件蓝领”去查下去年的帖子，看看同意这个观点的人多不多？>> 真不知道你是做什么行业的，连这个都不知道
呵呵我刚被炒了鱿鱼现在失业中，什么行业都不做，连soho都不做的。你说的我也都大略知道，不过觉得这两年来国内对这一块重视多了。>> OO是伟大的革新，合理的使用OO能带来很多好处。不知道OO的哪里让你产生了不满？ 我没有对OO不满，只是拿它出来做个比喻而已，因为我觉得你对b/s的抵触情绪有点类似于我以前从结构化编程转OO的感受：明明很简单的事情无缘无故弄得很复杂。>>而BS是什么？是搭建在静态HTML之上的，以补丁方式产生动态效果的技术。这个我还真的理解不了，什么叫做“搭建在静态HTML之上的，以补丁方式产生动态效果的技术”？脚本和css叫做补丁？
如果b/s只是这样的一种技术，那么c/s又是怎样的一种技术？>> 同时它也是浏览器大战的产物，留下了乱七八糟一大堆非技术因素的东西。
b/s怎么会是浏览器大战的产物？？根本就不是一个年代发生的故事。>> 关于“合理分工”
你谈的很虚，我不知道如何回答你的问题，确实你讲的问题都存在（当然你是夸大了的），但是并没有妨碍到我们做b/s，而c/s也一样有它自己的问题或者和b/s一样的问题。比如专业设计界面人的就是帮不上编程的忙，比如OT和delay，不管是b/s还是c/s都是一样的麻烦。>> 关于“更新不方便”
你描述的很理想，也许你的客户会喜欢吧，我的客户就难说了。你的几百k的client能设计进去多少功能多少界面我也不得而知（或者每个frame一个client？），不做评论。>> 我们这个论坛用BS很好，但是要是让你当个银行职员一天八小时不停填form然后submit，你就知道什么才叫真正的“都够讨厌的”。
你终于都支持我的观点了，有的时候就是要用b/s才好。我可从来没有说过什么都要做成b/s。
顺便说一下，b/s也不是“不停填form然后submit”这么简单枯燥的。>> 我一直在等你说这么精典的话
明确一点吗，你支持吗？或者你还是认为“client(java swing)->|(EJB) 这样的结构可以做出能与 DHTML->servlet(control)->JSP/servlet(view)->java Bean->|(EJB) 一样复杂和灵活的系统”？
>> 业务逻辑在EJB中，不在JSP与servlet或是bean中，那为什么要用JSP,servlet与bean？因为要适应HTML
业务逻辑在function中，那为什么要object呢？因为要适应OO。
b/s就是这样一个结构，你非要说它的这里那里是多余的，那么也可以说OO带来的新概念全部都是多余的。没有OO我们一样可以写出来任何程序。>> 有必要的分类与没必要分类硬分类之间还是很大不同的吧?
你是认为html，css和js是“必要分类硬分类”？？
你是认为html，css和js是“没必要分类硬分类”？？
---------------------------------------
我正是如此认为，css与js就是对html没有动态功能的html的一种client端补救。而asp，php,jsp就是对html没有动态功能的后端补救。但是各种补救各行其道，产生基础功能模块不紧凑不正交（注意紧凑与正交两词，如果不知道建意你去看看教课书）。
------------------------------------------
>> 所以coding是“微不足道的”——可以交给高中生去做
这是去年刘兴波大记者的论调了，你可以用关键字“软件蓝领”去查下去年的帖子，看看同意这个观点的人多不多？
------------------------------------------
同意这个观点的人多不多我不知道，我只知道印度就是这么做的（而不只是这么说的或这么想的），而且印度软件出口强中国百倍不只。而且这也是软件工程里所述。-------------------------------
呵呵我刚被炒了鱿鱼现在失业中，什么行业都不做，连soho都不做的。你说的我也都大略知道，不过觉得这两年来国内对这一块重视多了。
-------------------------------
我也失业中，去年9月辞的职一直没工作。辞职就是因为看不惯国内的软件开发方式（只能用野蛮来形容和未开化来形容）
-------------------------------
我没有对OO不满，只是拿它出来做个比喻而已，因为我觉得你对b/s的抵触情绪有点类似于我以前从结构化编程转OO的感受：明明很简单的事情无缘无故弄得很复杂。
-------------------------------
OO与BS性质跟本不同好不好？谁不是从面向过程转到OO的？我学会OO之后可没说过它什么坏话，而且还为有这种东东感动不已。你可以说OO把问题弄的很复杂（从某种角度来说），但你不能说“无缘无故”（对不对？）-------------------------------
如果b/s只是这样的一种技术，那么c/s又是怎样的一种技术？
-------------------------------
CS至少不是一种当有新的需求来到就发明一种新的语言的技术，至多会提供新的类与函数库。（就是所谓的紧凑）-------------------------------
b/s怎么会是浏览器大战的产物？？根本就不是一个年代发生的故事。
-------------------------------
至今IE与NetScape仍有大量不兼容成份，而IE与N也都不能做到与自己之前版本的向后兼容。好比DOM，象联合国似的，好象比较公正，但谁也不听他的----------------------------------------
比如专业设计界面人的就是帮不上编程的忙
----------------------------------------
CS也有这问题，但BS的技术线太长，问题所以更严重一些。而这种技术线长度是没有必要的。这个所谓的标准更大程度上是历史背景和浏览器之间竞争的产物，而不是合理的设计流程的成果。（这话是我的JavaScript书上说的（JavaScript完全手册P109）），再看后台，为什么分出JSP,Bean,servlet，就是因为HTML或者说是web page方式，最终什么都放在一起给B，这么多东西就是为了先把他们分开（为了写着改着用着方便），代码是代码，数据是数据，界面是界面，然后在组合在一起（因为web page就逮就样）。--------------------------------------
你描述的很理想，也许你的客户会喜欢吧，我的客户就难说了。你的几百k的client能设计进去多少功能多少界面我也不得而知（或者每个frame一个client？），不做评论。
--------------------------------------
很理想吗？你的客户都是你的孙子，所以一点也不难说。让我告诉你，这不是理想，而是现实，你从sun的网站下一个pet store在server端部署好之后就可以看到这个“理想”的实现。我的client只有几百K，不是说没有办法弄得大一些但是通常就是这么大，而且功能可以非常之多。原因很简单，第一在你的browser之中有jdk库，所以不会再被下载。第二，绝大多数功能实现不会被下载到client，client只有一些桩，也就是远程调用接口，他把数据以参数形式传到server端计算，功能实现只在server端有。而且这一切都由java的内部机制支持，在写程序的时候你就好象在使用一个本地对象（而其实在server端运行,相对BS的优势立显了吧？）。你不用等用户submit，你随时可以与server通信。而且有些类可以直到需要时再下载。最后再说一便，这一切的一切不是理想，而是业已存在的事实(你对CS的概念落伍了，象很多人一样，你在拿最先进的或是未来的BS技术比较最古老的CS技术)！------------------------------------------
你终于都支持我的观点了，有的时候就是要用b/s才好。我可从来没有说过什么都要做成b/s。
顺便说一下，b/s也不是“不停填form然后submit”这么简单枯燥的。
------------------------------------------
我不是第一次说BS在某些情况下是正确选择了，找一找，说了很多便了。submit的坏处就在于即便web server在本地，刷新也不快(这与web server的机制有关)。你上CSDN看看贴子没有什么，但是银行里的客户排队站在柜台前等你操作好计算机就是另一码子事了，你输入也许飞快，但你逮等web page显示出来。--------------------------------------------
明确一点吗，你支持吗？或者你还是认为“client(java swing)->|(EJB) 这样的结构可以做出能与 DHTML->servlet(control)->JSP/servlet(view)->java Bean->|(EJB) 一样复杂和灵活的系统”？
--------------------------------------------
不管多么复杂，CS只用一种语言，当我们有复杂的需求的时候，我们不会去添加一个新的语言，相对的我们会添加一个类，虽然一个类实现功能的方法是独特的，但是声名对象，调用其方法的语法是统一的，唯一的不同就是他的功能。--------------------------------------------
业务逻辑在EJB中，不在JSP与servlet或是bean中，那为什么要用JSP,servlet与bean？因为要适应HTML
业务逻辑在function中，那为什么要object呢？因为要适应OO。
b/s就是这样一个结构，你非要说它的这里那里是多余的，那么也可以说OO带来的新概念全部都是多余的。没有OO我们一样可以写出来任何程序。
--------------------------------------------
适应OO之后你可以解决重用，多态，封装的问题（你可以取舍放弃这些能力）
适应HTML之后你可以干什么？用client你不用去适应HTML也能达到这些目的。（你不用舍去任何能力）
OO在更高层次上把你的代码模块化，HTML相关技术在同一层次上把一相联系的问题打散。
你是认为html，css和js是“没必要分类硬分类”？？
---------------------------------------
我正是如此认为，css与js就是对html没有动态功能的html的一种client端补救。
------------------------------------------------------------------------
这是两种意思来的嘛。“没必要分类硬分类”意思就是说本来就是一类。
“css与js就是对html没有动态功能的html的一种client端补救”不错，我也这么认为，这一补救网页灵活漂亮了许多，b/s的很多功能也有了实现的可能。
“而asp，php,jsp就是对html没有动态功能的后端补救。”就莫名其妙了，这就是说s是b的补救，那么s也就是c的补救咯呵呵。-----------------------------------------------------------------------------
同意这个观点的人多不多我不知道，我只知道印度就是这么做的（而不只是这么说的或这么想的），而且印度软件出口强中国百倍不只。而且这也是软件工程里所述。
-----------------------------------------------------------------------------
一心只读圣贤书去了吧？关于印度的软件工程和开发模式去年网上和杂志都炒的够多了。“而且这也是软件工程里所述”是指的什么？是指可以随便找群高中生过来coding？
-----------------------------------------------------------------------------
OO与BS性质跟本不同好不好？谁不是从面向过程转到OO的？我学会OO之后可没说过它什么坏话，而且还为有这种东东感动不已。你可以说OO把问题弄的很复杂（从某种角度来说），但你不能说“无缘无故”（对不对？）
-----------------------------------------------------------------------------
对的很，当然不会无缘无故，我也只是借用你一个说法而已。“学BS的时候感觉很烦也是真的，因为明明很简单的事情无缘无故弄得很复杂”是你说的吧，难不成b/s就安了心要和大伙过不去非要“无缘无故”的弄复杂什么东西？
什么叫做“搭建在静态HTML之上的，以补丁方式产生动态效果的技术”？脚本和css叫做补丁？你还没给我解释呢？
-----------------------------------------------------------------------------
如果b/s只是这样的一种技术，那么c/s又是怎样的一种技术？
-------------------------------
CS至少不是一种当有新的需求来到就发明一种新的语言的技术，至多会提供新的类与函数库。（就是所谓的紧凑）
-----------------------------------------------------------------------------
那么b/s中又用到了哪种语言是特地为了b/s而发明的？
-----------------------------------------------------------------------------
b/s怎么会是浏览器大战的产物？？根本就不是一个年代发生的故事。
-------------------------------
至今IE与NetScape仍有大量不兼容成份，而IE与N也都不能做到与自己之前版本的向后兼容。好比DOM，象联合国似的，好象比较公正，但谁也不听他的
-----------------------------------------------------------------------------
你解释的和我问的颇对不上号哦。>> CS也有这问题，但BS的技术线太长，问题所以更严重一些。而这种技术线长度是没有必要的。这个所谓的标准更大程度上是历史背景和浏览器之间竞争的产物，而不是合理的设计流程的成果。（这话是我的JavaScript书上说的（JavaScript完全手册P109）），
呵呵，现在还迷信印刷品啊？作者偏见罢了。前几天还跟人说搞得到钱就躲起来写本书呵呵。-------------------------------------------------------------------------
再看后台，为什么分出JSP,Bean,servlet，就是因为HTML或者说是web page方式，最终什么都放在一起给B，这么多东西就是为了先把他们分开（为了写着改着用着方便），代码是代码，数据是数据，界面是界面，然后在组合在一起（因为web page就逮就样）。
-------------------------------------------------------------------------
怎么说的好像b/s都是java的天下了似的？看看web板下面分多少个小板块？再说了“代码是代码，数据是数据，界面是界面”简直就是梦想中的乌托邦，我们一直愁的是分的不够开，你倒担心搅和不到一快去了呵呵。你查看过这个帖子的页面原码吗？这个xml中就没有定义过显示格式，全是数据（和数据格式）。--------------------------------------------------------------------------
很理想吗？你的客户都是你的孙子，所以一点也不难说。让我告诉你，这不是理想，而是现实
--------------------------------------------------------------------------
我没有置疑过它的可实现性，毕竟我在这个模式下的pvcs下面工作过半年多。我只是怀疑大家会不会真的喜欢它，我作为一个用户的感觉就是：网页不象网页，客户端不象客户端，感觉毕竟不爽。不过这当然纯属个人使用习惯问题。
我的客户不是我的孙子，我是他们的孙子，他们要我IE5+我就IE5+，他们要我NS6+我就NS6+ :))>> 你在拿最先进的或是未来的BS技术比较最古老的CS技术
我只是拿我所用的和我所知道的b/s技术来比较我所知道的和你所介绍的c/s技术罢了>> 你不用等用户submit，你随时可以与server通信。
c/s可以不刷新页面更新数据，b/s也一样可以（我知道的实现方式至少有5种），主要看实现风格和客户需求了。
>>我不是第一次说BS在某些情况下是正确选择了，找一找，说了很多便了。
是第二次，第一次是“做为internet门户用BS简直是无可辩驳”。
>> submit的坏处就在于即便web server在本地，刷新也不快(这与web server的机制有关)。你上CSDN看看贴子没有什么，但是银行里的客户排队站在柜台前等你操作好计算机就是另一码子事了，你输入也许飞快，但你逮等web page显示出来。b/s常常submit，但是b/s并不等于submit。b/s也更不等于慢。在局域网中下载一个页面需要的时间很短，而s端需要做的计算b/s不见得比c/s多多少。论坛嘛，在线人数实在太多，用c/s也快不起来。>> 不管多么复杂，CS只用一种语言，当我们有复杂的需求的时候，我们不会去添加一个新的语言，相对的我们会添加一个类，虽然一个类实现功能的方法是独特的，但是声名对象，调用其方法的语法是统一的，唯一的不同就是他的功能。呵呵，我只举一个反例就够了：SQL
---------------------------------------------------------------------------
适应OO之后你可以解决重用，多态，封装的问题（你可以取舍放弃这些能力）
适应HTML之后你可以干什么？用client你不用去适应HTML也能达到这些目的。（你不用舍去任何能力）
OO在更高层次上把你的代码模块化，HTML相关技术在同一层次上把一相联系的问题打散。
---------------------------------------------------------------------------结构化已经解决了重用的问题：函数。多态和封装，而对于实现功能都不是必须的。用你强力推荐的client：pet-store，能够完全抛开HTML的支持吗？
OO对于善用的人来说，在更高层次上把你的代码模块化；HTML相关技术对不善使用的人来说，在同一层次上把一相联系的问题打散。
“css与js就是对html没有动态功能的html的一种client端补救”不错，我也这么认为，这一补救网页灵活漂亮了许多，b/s的很多功能也有了实现的可能。
“而asp，php,jsp就是对html没有动态功能的后端补救。”就莫名其妙了，这就是说s是b的补救，那么s也就是c的补救咯呵呵。
这一补救不是紧凑同构的（明白吗？）
asp,php是为了动态凑HTML而生，大量增大了解决业务无关问题所需时间。>>------------------------------------------------
同意这个观点的人多不多我不知道，我只知道印度就是这么做的（而不只是这么说的或这么想的），而且印度软件出口强中国百倍不只。而且这也是软件工程里所述。
--------------------------------------------------
印度是这么做的而且成功了，不管你东说西说些什么，人家是以事实来证明的。“而且这也是软件工程里所述”是指我所说的详设的范围。“随便找群高中生过来coding？”我有说过“随便”两个字吗？为什么一定要“随便”？
>>-----------------------------------------------------------------------------
OO与BS性质跟本不同好不好？谁不是从面向过程转到OO的？我学会OO之后可没说过它什么坏话，而且还为有这种东东感动不已。你可以说OO把问题弄的很复杂（从某种角度来说），但你不能说“无缘无故”（对不对？）
-----------------------------------------------------------------------------
对的很，当然不会无缘无故，我也只是借用你一个说法而已。“学BS的时候感觉很烦也是真的，因为明明很简单的事情无缘无故弄得很复杂”是你说的吧，难不成b/s就安了心要和大伙过不去非要“无缘无故”的弄复杂什么东西？
BS不是“安了心”，却正是因为没有合理设计产生的恶果。
什么叫做“搭建在静态HTML之上的，以补丁方式产生动态效果的技术”？脚本和css叫做补丁？你还没给我解释呢？
CSS与脚本正是补丁，以上HTML产生动态效果——有什么问题吗？
>>-----------------------------------------------------------------------------
如果b/s只是这样的一种技术，那么c/s又是怎样的一种技术？
-------------------------------
CS至少不是一种当有新的需求来到就发明一种新的语言的技术，至多会提供新的类与函数库。（就是所谓的紧凑）
-----------------------------------------------------------------------------
那么b/s中又用到了哪种语言是特地为了b/s而发明的？
JSP，PHP，JavaScript,CSS,bean,是特地为弥补原HTML不足而发明的。
-----------------------------------------------------------------------------
b/s怎么会是浏览器大战的产物？？根本就不是一个年代发生的故事。
-------------------------------
至今IE与NetScape仍有大量不兼容成份，而IE与N也都不能做到与自己之前版本的向后兼容。好比DOM，象联合国似的，好象比较公正，但谁也不听他的
-----------------------------------------------------------------------------
你解释的和我问的颇对不上号哦。
有什么对不上号？
>> CS也有这问题，但BS的技术线太长，问题所以更严重一些。而这种技术线长度是没有必要的。这个所谓的标准更大程度上是历史背景和浏览器之间竞争的产物，而不是合理的设计流程的成果。（这话是我的JavaScript书上说的（JavaScript完全手册P109）），
呵呵，现在还迷信印刷品啊？作者偏见罢了。前几天还跟人说搞得到钱就躲起来写本书呵呵。
有没有偏见不是你说了算吧？
-------------------------------------------------------------------------
再看后台，为什么分出JSP,Bean,servlet，就是因为HTML或者说是web page方式，最终什么都放在一起给B，这么多东西就是为了先把他们分开（为了写着改着用着方便），代码是代码，数据是数据，界面是界面，然后在组合在一起（因为web page就逮就样）。
-------------------------------------------------------------------------
怎么说的好像b/s都是java的天下了似的？看看web板下面分多少个小板块？再说了“代码是代码，数据是数据，界面是界面”简直就是梦想中的乌托邦，我们一直愁的是分的不够开，你倒担心搅和不到一快去了呵呵。你查看过这个帖子的页面原码吗？这个xml中就没有定义过显示格式，全是数据（和数据格式）。对啊，“代码是代码，数据是数据，界面是界面”多好啊，CS在这方面不是更好些吗？BS还是托HTML的福最终还是要放在一起而且要按它的不那么高明的结构。
--------------------------------------------------------------------------
很理想吗？你的客户都是你的孙子，所以一点也不难说。让我告诉你，这不是理想，而是现实
--------------------------------------------------------------------------
我没有置疑过它的可实现性，毕竟我在这个模式下的pvcs下面工作过半年多。我只是怀疑大家会不会真的喜欢它，我作为一个用户的感觉就是：网页不象网页，客户端不象客户端，感觉毕竟不爽。不过这当然纯属个人使用习惯问题。
我的客户不是我的孙子，我是他们的孙子，他们要我IE5+我就IE5+，他们要我NS6+我就NS6+ :))
你的客户喜欢什么难道是由象不象网页还是象不象client决定的？？？我看，很简单功能，性能，易用性，高效性全做到就让人喜欢。windows刚出来的时候也有很多人不喜欢，Browser刚出来的时候还是有很多人不喜欢，刚有人说地球是圆的的时候不高兴的人还要多的多！
>> submit的坏处就在于即便web server在本地，刷新也不快(这与web server的机制有关)。你上CSDN看看贴子没有什么，但是银行里的客户排队站在柜台前等你操作好计算机就是另一码子事了，你输入也许飞快，但你逮等web page显示出来。
如果你真了解什么是web request->servlet->JSP->tag+bean->|EJB，你就应该知道里面有多少胶合代码，你就应该想到为什么它会慢。如果你知道每次reuest的时候都要把cookie传一遍（不管有用没用），你就应该想到为什么它会慢。如果你知道web server的非长连接方式，你就应该想到为什么它会慢。>> 不管多么复杂，CS只用一种语言，当我们有复杂的需求的时候，我们不会去添加一个新的语言，相对的我们会添加一个类，虽然一个类实现功能的方法是独特的，但是声名对象，调用其方法的语法是统一的，唯一的不同就是他的功能。呵呵，我只举一个反例就够了：SQL
hehe,就在等你说这个，试观察java与SQL，两者分工明确，都是完备紧凑与自包含的。再看看HTML相关技术，大多数不是。SQL是数据库语言，java是程序语言，SQL并不是java要管理数据库的时候发明出来的嵌入java的新语法与新语句。JDBC确实提供了两者之间的接口，但它仍旧是一些类。你的SQL语句只是数据（对java来说）。话说回来，即便如此，这种在一种代码中内嵌另一种代码的事情还是应该尽量减少。（看看cmp entity EJBean你就会了解什么叫没有SQL的数据库代码）
---------------------------------------------------------------------------
适应OO之后你可以解决重用，多态，封装的问题（你可以取舍放弃这些能力）
适应HTML之后你可以干什么？用client你不用去适应HTML也能达到这些目的。（你不用舍去任何能力）
OO在更高层次上把你的代码模块化，HTML相关技术在同一层次上把一相联系的问题打散。
---------------------------------------------------------------------------
结构化已经解决了重用的问题：函数。多态和封装，而对于实现功能都不是必须的。用你强力推荐的client：pet-store，能够完全抛开HTML的支持吗？
pet store没有完全抛开HTML，这倒是真的，但是你发现没有，他只有在对C（也就是internet用户）的时候才用HTML，对企业内部员工，管理人员用的是client
最后还要说清一点，我针对BS是针对其HTML相关技术。对于象applet这类东西我没有丝毫的不认同的意思