整天听说C/S B/S架构 有一个低级的问题想问

[sinomac]

整天听说C/S B/S架构 有一个低级的问题想问
B/S略知一二，
C/S问题，
C是客户端，这个没就疑问，
S是服务器端，这里有个问题是，这个服务器端指的是SQL SERVER 还是需要开发一个服务器端？
但是不开发一个服务器端的话，我一样在客户端可以远程连接到MSSQL呀。

我是说我的数据库用的是MSSQL，

[CShareMySide]

S是一个服务器端，可以理解成IIS吧，B/S的话如果没有IIS，S将也不存在

C/S中的S一般用WCF、Remoting、WebServices来担任，并不是MSSQL

[wzr_8703]

比如说QQ吧。在你电脑上运行的，就是C端。
但是你经常会接收到弹出框新闻，好友请求，等等，这些不都是S端发送出来的吗？

服务器端，不仅仅是指DB，如果需要，可以有操作界面什么的。

[窗户纸]

其实B/S，C/S之间的关系可以说越来越暧昧：
1. 早先b/s一般都指 瘦客户端，即业务逻辑都在服务器，客户端只起数据显示的作用，但B/S的推行者发现这样他们太吃亏，因为C/S在性能上的优势就太明显了，于是B/S也搞WEB2.0, AJAX等，把业务逻辑搞到客户端去了。
2. C/S一般都指每个业务逻辑需要定制的开发，因此部署麻烦，但自从出了个smartclient之后，似乎今后定制逻辑可以很轻松的透明的部署到客户端去了。

所以类似于天下合久必分，分久必合的道理，B/S与C/S我看今后也会殊途同归了。

但当前的情况是，B/S架构的根本是浏览器，所有的客户端业务逻辑必须通过浏览器进行“翻译”才能执行。因此众多厂商都在争夺新一代的浏览器体系（都在打破头搞什么双核），谁占有了浏览器，谁就控制了未来的体系，但是问题是目前的浏览器仍是基于HTTP或XML这种通信效率损耗极大的底层通信协议，因此各家打破头最终还是个平局。

哪天如果真出现个新的底层技术，统一了C/S与B/S的话，可能技术体系就会发生超级大变革了。

[hinada99]

路过帮忙顶起~~

[以专业开发人员为伍]

[Quote=引用楼主 sinomac 的回复:]
整天听说C/S B/S架构 有一个低级的问题想问
B/S略知一二，
C/S问题，
C是客户端，这个没就疑问，
S是服务器端，这里有个问题是，这个服务器端指的是SQL SERVER 还是需要开发一个服务器端？
但是不开发一个服务器端的话，我一样在客户端可以远程连接到MSSQL呀。

我是说我的数据库用的是MSSQL，
[/Quote]

使用一种c/s数据库，访问它的客户端驱动，于是以访问本地数据库的方式去访问远程数据库，这被许多人以为是“标准的”c/s程序。其实这只是人家数据库是c/s的而已。

可以看一个很简单的例子。比如我们都要发短信、打电话，我们的手机可不是使用什么数据库的客户端驱动来访问移动公司的数据库，而是客户端程序去访问服务器端系统。服务器端系统使用了什么数据库，有多少台机器，有哪些功能集成了别的系统，对于客户端程序来说都是隐藏的。服务器端系统随时重构，与客户端程序毫无关系。

[以专业开发人员为伍]

比如我们通过即时聊天软件来聊天，可以通过（不同型号的）手机上的几十种软件，（不同操作系统的）PC上的十几种软件，甚至可以通过网页，对方哪一个客户端在线就会立刻参与聊天，这就是c/s的应用系统架构，c端根本无权知道s端的内部细节（更不可能通过知道数据库的登录密码就去随便翻阅所有数据资料），只能访问s的业务接口。而s端编程时对客户端的位置、协议、权限、数据流转等等都有自己的一套，不管客户端从哪一个地方登录，哪怕是通过电冰箱来访问服务器，也跟手机或者PC是一样地被同一套业务服务器来管理的。

当你开发软件，只是为了能够随意读取远程数据库里的数据，这个从概念上就只是对c/s系统架构的最低级的需求。你提不出一个大系统的需求，就会选择那种c/s数据库的客户端来驱动作为自己的“c/s程序”。

[kingdom_0]

[Quote=引用 4 楼 sp1234 的回复:]

比如我们通过即时聊天软件来聊天，可以通过（不同型号的）手机上的几十种软件，（不同操作系统的）PC上的十几种软件，甚至可以通过网页，对方哪一个客户端在线就会立刻参与聊天，这就是c/s的应用系统架构，c端根本无权知道s端的内部细节（更不可能通过知道数据库的登录密码就去随便翻阅所有数据资料），只能访问s的业务接口。而s端编程时对客户端的位置、协议、权限、数据流转等等都有自己的一套，不管客户端从哪一个地……
[/Quote]学习了。

[大山里的松]

c/s 即使客户/服务器 模式，它的发展经历的 从 胖到瘦的过程
B/S 即浏览器/服务器 模式，同时我们也可以理解为 B （Browser）就是很瘦的 C （Client）。

最初，在胖客户端的应用中，S端指的是 dbms， 胖客户端中包含了所有的表示、业务逻辑和数据库访问，通过odbc， oledb 以及其他方式连接DB，进行 CRUD的操作。
后来，发展了，出现了三层体系架构，和多层体系架构，从逻辑上将胖客户端分成了若干层，其中一部分就剥离出去成了服务端应用服务器。 B/S中的S 一般可以理解为Web服务器。

后来又发展了， 因为瘦客户端应用固然有其一定的优势，比如能充分利用客户机的计算资源，但是对于安装和部署等，对于一般用户来讲可能过于繁琐（期间又出现了SmartClient应用），于是B/S应用流行起来。客户端变成了更瘦的浏览器，开发者主要的经历放在了服务器端的开发，客户端浏览器中开发仅仅局限在了UI和脚本层面。

后来，Web2.0的出现 ＲＩＡ　流行起来，　结合了BS和CS的优势，但个人理解 ＣＳ　ＢＳ　ＲＩＡ等，各有其使用的环境，谁也不能替代谁，要根据实际需求来确定使用何种开发模式。

[ZMAK_Chun]

[Quote=引用 4 楼 sp1234 的回复:]

比如我们通过即时聊天软件来聊天，可以通过（不同型号的）手机上的几十种软件，（不同操作系统的）PC上的十几种软件，甚至可以通过网页，对方哪一个客户端在线就会立刻参与聊天，这就是c/s的应用系统架构，c端根本无权知道s端的内部细节（更不可能通过知道数据库的登录密码就去随便翻阅所有数据资料），只能访问s的业务接口。而s端编程时对客户端的位置、协议、权限、数据流转等等都有自己的一套，不管客户端从哪一个地……
[/Quote]谢谢！

[nbhx2010]

C/S里的最简单的模式就是客户端程序加一个数据库服务器（甚至无数据库服务器）
绝大部分人一定要把C/S理解成客户端程序，服务器段程序
实际上很多程序，不一定都要有S端程序
比如，一个管理项目，客户端加数据库就可以了。。。。

另外，当然有比较标准的C/S模式，就是客户端+服务器段程序+数据库（可有可无）
比如你有很多客户端命令，需要统一到服务器段程序处理后再发出去，
那么这个时候就形成标准的C/S模式了，就是有客户端程序，有服务器段程序

但是这并不表示通常只有一个客户端加数据库的就不是C/S模式了

[qw_zr]

对于S来说，它是自己写的服务器，而不是SQL SERVER。通常S用WCF，Webservices或者单纯的TCP/UDP来实现。
用Sql Server确实可以实现服务器，但是这是极度不安全的，应当避免那样做。因为那样就意味着数据库暴露在了客户端面前，客户端可以做几乎任何事（只要破解了Sqlserver的密码）。要知道，客户端如何能直接远程连接SQL Server，就意味着可以轻易通过反编译获得连接时用到的密码。

[一只眼足矣看码]

S就是服务器

b/s c/s 可见 S代表的是相同的， 不同的部分只是 B 或 C C是客户端，B是浏览器

[threenewbee]

几乎99%的人对B/S的理解有误区。

事实上Browser是一种特定的Client程序，所以B/S是C/S的特例。

同样，服务器端只有数据库，也是C/S的特例，使用客户端-应用服务器-数据库服务器的模式，就是三层架构。

[山书生]

这问题，没纠结过。c/s即c/s

[sinomac]

9楼的兄弟说的：比如，一个管理项目，客户端加数据库就可以了。。。。

10的见解。
对于S来说，它是自己写的服务器，而不是SQL SERVER。通常S用WCF，Webservices或者单纯的TCP/UDP来实现。
用Sql Server确实可以实现服务器，但是这是极度不安全的，应当避免那样做。因为那样就意味着数据库暴露在了客户端面前，客户端可以做几乎任何事（只要破解了Sqlserver的密码）。要知道，客户端如何能直接远程连接SQL Server，就意味着可以轻易通过反编译获得连接时用到的密码。


我想要的就是跟9楼所说，只是做一个工作上的流程管理，但需要分公司通过网络连接并处理业务
这时我服务端就不能单纯的MSSQL了吧？