问题描述
现在编程趋势都是倾向于B/S模式了，都是做网站的。那么，如题............
解决方案
解决方案二：
在一些领域CS还是有一定比例的。比如金融和医疗，特别是想股票，期货这类需要很快响应的。
解决方案三：
我就是做CS领域的，感觉还行。
解决方案四：
优势很多，首先就是灵活性。B/S严格来说，也属于C/S，只是Client特化成Browser了。那么显然你自己写客户端，能做的事情比一个标准浏览器多多了，比如说访问硬件、访问本地的各种资源、可以轻易实现更复杂的界面、可以在客户端放更重的业务逻辑等等。和服务器的通讯也不局限于http/tcp协议。
解决方案五：
该回复于2014-09-20 01:03:57被版主删除
解决方案六：
引用3楼devmiao的回复:
优势很多，首先就是灵活性。B/S严格来说，也属于C/S，只是Client特化成Browser了。那么显然你自己写客户端，能做的事情比一个标准浏览器多多了，比如说访问硬件、访问本地的各种资源、可以轻易实现更复杂的界面、可以在客户端放更重的业务逻辑等等。和服务器的通讯也不局限于http/tcp协议。
百度百科解释：BS维护简单，只需要维护服务器版本即可。
解决方案七：
我是学编程，现在学习到不少东东
解决方案八：
C#的优势就是在windows下窗口,有很多东西可以利用
解决方案九：
引用5楼zhi_ai_yaya的回复:
Quote: 引用3楼devmiao的回复:
优势很多，首先就是灵活性。B/S严格来说，也属于C/S，只是Client特化成Browser了。那么显然你自己写客户端，能做的事情比一个标准浏览器多多了，比如说访问硬件、访问本地的各种资源、可以轻易实现更复杂的界面、可以在客户端放更重的业务逻辑等等。和服务器的通讯也不局限于http/tcp协议。百度百科解释：BS维护简单，只需要维护服务器版本即可。
B/S也要维护客户端，君不见IE每个月都在发更新补丁，Chrome更是日日更新。只是B/S作为C/S的特例，更新客户端的任务就由浏览器厂商代劳了。
解决方案十：
优势在于不受浏览器限制。现在浏览器五花八门，做B/S的都会免不了受浏览器兼容性困扰。
解决方案十一：
引用9楼andywangguanxi的回复:
优势在于不受浏览器限制。现在浏览器五花八门，做B/S的都会免不了受浏览器兼容性困扰。
同意,做B/S时要用最少两个浏览器进行测试,否则页面布局首先是个大问题!
解决方案十二：
BS用于管理信息方面比较多，优点是维护方便，不需要挨个更新客户端。CS则如3楼所言，优势也是很明朗的。
解决方案十三：
引用8楼devmiao的回复:
Quote: 引用5楼zhi_ai_yaya的回复:
Quote: 引用3楼devmiao的回复:
优势很多，首先就是灵活性。B/S严格来说，也属于C/S，只是Client特化成Browser了。那么显然你自己写客户端，能做的事情比一个标准浏览器多多了，比如说访问硬件、访问本地的各种资源、可以轻易实现更复杂的界面、可以在客户端放更重的业务逻辑等等。和服务器的通讯也不局限于http/tcp协议。百度百科解释：BS维护简单，只需要维护服务器版本即可。
B/S也要维护客户端，君不见IE每个月都在发更新补丁，Chrome更是日日更新。只是B/S作为C/S的特例，更新客户端的任务就由浏览器厂商代劳了。
怎么我总感觉有点不对？浏览器的更新和维护是浏览器厂商的事情，兼容浏览器的问题，这不是服务器程序的任务吗？-------摘自百度百科-B/S结构---------------2架构特点编辑（1）维护和升级方式简单。当前，软件系统的改进和升级越发频繁，B/S架构的产品明显体现着更为方便的特性。对一个稍微大一点单位来说，系统管理人员如果需要在几百甚至上千部电脑之间来回奔跑，效率和工作量是可想而知的，但B/S架构的软件只需要管理服务器就行了，所有的客户端只是浏览器，根本不需要做任何的维护。无论用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行；如果是异地，只需要把服务器连接专网即可，实现远程维护、升级和共享。所以客户机越来越“瘦”，而服务器越来越“胖”是将来信息化发展的主流方向。今后，软件升级和维护会越来越容易，而使用起来会越来越简单，这对用户人力、物力、时间、费用的节省是显而易见的，惊人的。因此，维护和升级革命的方式是“瘦”客户机，“胖”服务器。
解决方案十四：
引用12楼zhi_ai_yaya的回复:
Quote: 引用8楼devmiao的回复:
Quote: 引用5楼zhi_ai_yaya的回复:
Quote: 引用3楼devmiao的回复:
优势很多，首先就是灵活性。B/S严格来说，也属于C/S，只是Client特化成Browser了。那么显然你自己写客户端，能做的事情比一个标准浏览器多多了，比如说访问硬件、访问本地的各种资源、可以轻易实现更复杂的界面、可以在客户端放更重的业务逻辑等等。和服务器的通讯也不局限于http/tcp协议。百度百科解释：BS维护简单，只需要维护服务器版本即可。
B/S也要维护客户端，君不见IE每个月都在发更新补丁，Chrome更是日日更新。只是B/S作为C/S的特例，更新客户端的任务就由浏览器厂商代劳了。
怎么我总感觉有点不对？浏览器的更新和维护是浏览器厂商的事情，兼容浏览器的问题，这不是服务器程序的任务吗？-------摘自百度百科-B/S结构---------------2架构特点编辑（1）维护和升级方式简单。当前，软件系统的改进和升级越发频繁，B/S架构的产品明显体现着更为方便的特性。对一个稍微大一点单位来说，系统管理人员如果需要在几百甚至上千部电脑之间来回奔跑，效率和工作量是可想而知的，但B/S架构的软件只需要管理服务器就行了，所有的客户端只是浏览器，根本不需要做任何的维护。无论用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行；如果是异地，只需要把服务器连接专网即可，实现远程维护、升级和共享。所以客户机越来越“瘦”，而服务器越来越“胖”是将来信息化发展的主流方向。今后，软件升级和维护会越来越容易，而使用起来会越来越简单，这对用户人力、物力、时间、费用的节省是显而易见的，惊人的。因此，维护和升级革命的方式是“瘦”客户机，“胖”服务器。
百度百科你也信
解决方案十五：
楼猪不要纠结了。哪个时候windows不用winfrom了再考虑这些问题。
解决方案：
BS部署和维护相对简单,也不需要在每个客户机都安装客户端软件,但是限制也是挺多的1.浏览器版本太多,稍有不慎就会出现某些浏览器无法显示或功能不正常2.响应速度慢,每次客户端回发,服务端都要生成一个html页传递给客户端,这比CS直接读数据肯定是要偏慢,对于实时性要求高的场景不太适用.3.不能直接操作客户机的硬件.2+3,有办法可以规避,比如增加浏览器插件(Active控件),但是依然不能像CS一样灵活控制比如QQ这款软件,你非要做成BS的,那么很多功能都无法实现了比如点对点传输,比如截屏(总不能每次截屏前必须打开IE吧)而且有些应用是需要做成服务,在后台运行的,必须打开IE才能使用,科学么
解决方案：
我是不愿意调试那些看着貌似很规范的js代码。
解决方案：
各有优势，这还有疑问？！
解决方案：
其实，本来就可以用WINFORM用WEBKIT写一个类似浏览器的工具出来。本来这个问题没有必要纠结，C/S有C/S的工作方式，B/S也有B/S的工作方式，使用方愿意这么用就怎么用，初学者一般只能看见表象，以为浏览器易部署就好像还不错。下面，就请先回答几个问题:1.安装操作系统的时候，系统是否以及默认带有常用的或者自己熟悉的浏览器？2.如果(1)没有，是否需要自己下载安装并且配置对应项？显而易见，B/S在多次部署的时候可能不需要做那么多次，但是第一次运用时，同样还是要转对终端进行部署安装以及设置。
解决方案：
说bs会全面取代cs,是偏激的说法,是片面的你看现在手机用户这么多,难道手机就能取代PC了吗以后就不再生产PC了,也不再生产服务器了,都用手机代替?那是不可能的.各有各的用途,谁也代替不了谁
解决方案：
C/S灵活，美观，方便，话说浏览器的也属于C/S
解决方案：
其实B/S也就是C/S，因为那个C是浏览器，不需要自己做了。但是不能浏览器表现效果也不一样，如果做前端设计就很清楚这个B/S不是想象中的那么美好。顺便一说，你做C/S的时候，如果做成瘦客户端模式，主要工作都是由服务器完成，客户端只是输出显示，那和B/S差不多了。现在移动客户端大多是这么设计的。
解决方案：
引用20楼bjf814的回复:
C/S灵活，美观，方便，话说浏览器的也属于C/S
首字母写错了
解决方案：
引用22楼WM_JAWIN的回复:
Quote: 引用20楼bjf814的回复:
C/S灵活，美观，方便，话说浏览器的也属于C/S首字母写错了
解决方案：
b/s硬件接口相关的不行b/s要考虑浏览器兼容性b/s不能单机
解决方案：
引用13楼devmiao的回复:
百度百科你也信
按大神的意思，从不信百度百科，不管对否错否片面否？每个人应该有自己的思考能力，但是不代表任何现成的东西都不可信，不是只有权威专家说的才有道理。虽然百度百科是水，很多描述都算是“肤浅”，不够专业，但是并不是一无是处，而且我引用的那段话，自认为描述的还算可取。维护和升级革命的方式是“瘦”客户机，“胖”服务器，这的确符合现在行业的发展趋向：云。
解决方案：
引用24楼angel6709的回复:
b/s硬件接口相关的不行b/s要考虑浏览器兼容性b/s不能单机
b/s不能单机是个致命伤前两条都有办法解决,就是不能单机这点实在是要命我就做个excel处理的小程序,或者ping局域网ip的小程序,还要部署个服务器,还要打开ie才能用,不是坑爹吗
解决方案：
赞楼上各位的答案，下面以控件市场分析、分析，欢迎大家拍砖：平台问题百分比Winform103873.41%ASP.NET1329.34%XAML20414.43%Other402.83%数据来源：备注：各个企业、行业不一，以上数据仅供参考。
解决方案：
引用楼主wr3crr4的回复:
现在编程趋势都是倾向于B/S模式了，都是做网站的。那么，如题............
不知道为什么你会这么说。我倒认为现在的趋势是倾向于所谓C/S。正如其他人提到的，如果你把浏览器看成客户端，那么B/S也属于C/S范畴。以往的“动态网站”实则是建立在“动态网页”上，即动态HTML而已。技术发展到现在，各种前端技术层出不穷，且不说移动端的Android,iOS这些东西，即使是做web，也跟以前大不一样了。你可以把后端做成完全的API提供者，前端几乎全部用JavaScript驱动——Ember,Angular,React,Backbone+Underscore,Knockout,Meteor...太多太多了，单页式web应用已经屡见不鲜。所谓后端稳重大气，前端百花齐放——以上，大体也就是如此了。
解决方案：
引用25楼zhi_ai_yaya的回复:
Quote: 引用13楼devmiao的回复:
百度百科你也信按大神的意思，从不信百度百科，不管对否错否片面否？每个人应该有自己的思考能力，但是不代表任何现成的东西都不可信，不是只有权威专家说的才有道理。虽然百度百科是水，很多描述都算是“肤浅”，不够专业，但是并不是一无是处，而且我引用的那段话，自认为描述的还算可取。维护和升级革命的方式是“瘦”客户机，“胖”服务器，这的确符合现在行业的发展趋向：云。
你贴出的东西显然不靠谱
解决方案：
话说,百度百科大部分都不怎么靠谱因为都不是官方的说法,而是注册用户修改的我要是有闲心,也可以没事上去给它改了
解决方案：
对于数据处理量大的用C/S，比如GIS行业的空间数据，本机把数据加工完了，再到服务器，要不然服务器的负担太大。B/S不能单机，C/S可以。
解决方案：
引用31楼liuhuibing12的回复:
对于数据处理量大的用C/S，比如GIS行业的空间数据，本机把数据加工完了，再到服务器，要不然服务器的负担太大。B/S不能单机，C/S可以。
BS也可以用JS实现分散控制吧,JS脚本在客户端执行,都处理好了再回发给服务端
解决方案：
引用12楼zhi_ai_yaya的回复:
Quote: 引用8楼devmiao的回复:
Quote: 引用5楼zhi_ai_yaya的回复:
Quote: 引用3楼devmiao的回复:
优势很多，首先就是灵活性。B/S严格来说，也属于C/S，只是Client特化成Browser了。那么显然你自己写客户端，能做的事情比一个标准浏览器多多了，比如说访问硬件、访问本地的各种资源、可以轻易实现更复杂的界面、可以在客户端放更重的业务逻辑等等。和服务器的通讯也不局限于http/tcp协议。百度百科解释：BS维护简单，只需要维护服务器版本即可。
B/S也要维护客户端，君不见IE每个月都在发更新补丁，Chrome更是日日更新。只是B/S作为C/S的特例，更新客户端的任务就由浏览器厂商代劳了。
怎么我总感觉有点不对？浏览器的更新和维护是浏览器厂商的事情，兼容浏览器的问题，这不是服务器程序的任务吗？-------摘自百度百科-B/S结构---------------2架构特点编辑（1）维护和升级方式简单。当前，软件系统的改进和升级越发频繁，B/S架构的产品明显体现着更为方便的特性。对一个稍微大一点单位来说，系统管理人员如果需要在几百甚至上千部电脑之间来回奔跑，效率和工作量是可想而知的，但B/S架构的软件只需要管理服务器就行了，所有的客户端只是浏览器，根本不需要做任何的维护。无论用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行；如果是异地，只需要把服务器连接专网即可，实现远程维护、升级和共享。所以客户机越来越“瘦”，而服务器越来越“胖”是将来信息化发展的主流方向。今后，软件升级和维护会越来越容易，而使用起来会越来越简单，这对用户人力、物力、时间、费用的节省是显而易见的，惊人的。因此，维护和升级革命的方式是“瘦”客户机，“胖”服务器。
兼容浏览器什么时候成了服务器程序的事情了？你写兼容的js不还是运行在浏览器中么？
解决方案：
引用33楼a01589的回复:
兼容浏览器什么时候成了服务器程序的事情了？你写兼容的js不还是运行在浏览器中么？
那js程序又在哪里,不是发布在服务器的iis上吗如果出了一款新的浏览器,而已有的js脚本不能兼容,不需要修改页面代码吗?
解决方案：
引用30楼Z65443344的回复:
话说,百度百科大部分都不怎么靠谱因为都不是官方的说法,而是注册用户修改的我要是有闲心,也可以没事上去给它改了
不是流行这样一种说法么：菜鸟看百度百科，用度娘专业一点的看维基百科，用谷歌而大神都看官方文档？
解决方案：
看个人习惯吧官方文档确实是最根本的,但是有些也写的语焉不详可能真正到了大神的境界,即使语焉不详也能照猫画虎的测试出来真正的用法菜鸟就只能看别人翻译成中文并详细解释,带源码的例子来照搬了
解决方案：
引用34楼Z65443344的回复:
Quote: 引用33楼a01589的回复:
兼容浏览器什么时候成了服务器程序的事情了？你写兼容的js不还是运行在浏览器中么？那js程序又在哪里,不是发布在服务器的iis上吗如果出了一款新的浏览器,而已有的js脚本不能兼容,不需要修改页面代码吗?
不钻牛角尖，理性讨论，js被称为客户端语言，不需要编译，如果要修改的话，只需要直接替换原有的页面即可。但是如果是服务器端语言，如ASP.NET，修改之后需要进行重新发布到IIS才行。
解决方案：
如果你要这么比是没有可比性的，只有在具体的实际应用环境中才能比较他们的优异
解决方案：
引用37楼a01589的回复:
Quote: 引用34楼Z65443344的回复:
Quote: 引用33楼a01589的回复:
兼容浏览器什么时候成了服务器程序的事情了？你写兼容的js不还是运行在浏览器中么？那js程序又在哪里,不是发布在服务器的iis上吗如果出了一款新的浏览器,而已有的js脚本不能兼容,不需要修改页面代码吗?
不钻牛角尖，理性讨论，js被称为客户端语言，不需要编译，如果要修改的话，只需要直接替换原有的页面即可。但是如果是服务器端语言，如ASP.NET，修改之后需要进行重新发布到IIS才行。
这么说也有道理.起码IIS不用重启了
解决方案：
看你应用的场景和应用领域了，嘴巴说这个哪个好都是扯淡，拿个具体的场景出来讨论是最佳的
解决方案：
c/s和b/s各有各的优势,两者结合起来使用更方便