用什么架构好？B/S对一套系统来说维护量小，但是有多套系统呢？解决方法
用什么架构好？B/S对一套系统来说维护量小，但是有多套系统呢？
举个例子，比如一套库存管理系统，多家客户使用，用什么架构比较好？
B/S号称维护量少，那是对一个客户而言，维护好服务器，客户端不用维护了。但是多个客户，就需要给每个客户来升级服务器端，反而更麻烦。尤其对于中小企业来说，让他们维护一个服务器很难，没有这种专人。软件公司要维护，那么就需要一个一个服务器逐个维护；
另外，企业数据放在托管的服务器上，很多企业不放心，感觉不安全，他们更倾向于自己有个服务器。
所以我感觉C/S架构的应该更适应这种情况，给客户一个升级包就可以了。可以让客户端自己升级，服务器基本不需要做什么操作。
C/S架构如何通过互联网访问，是否可以使用VPN？不知道大家有没有这么使用的？有什么心得？欢迎大家都来讨论。。。
------解决思路----------------------
再看你对c/s软件的概念，可以发现你在c/s上则是更加缺少知识的。
c/s不是指“只会写一个单机程序去调用关系数据库的驱动（例如ADO.NET驱动)”功能。这绝不是真正的c/s。你这种所谓的c/s，必然纠结什么vpn概念，因为你还是需要让所有人都用相同的账号密码去随便增删改查远程的数据库，而又担心安全性。
实际上，安全性远不是问题的主要矛盾。一个c/s是既有c又有s部分的，也就是说，你自己应该设计开发业务服务器Server。而你连企业业务服务器都不会设计，谈何c/s架构呢？一个企业业务服务器，就好像暴雪的游戏服务器似地，甚至更复杂，因为它要将你提供给各个企业的服务一网打尽。例如你的服务器要提供“即时通讯、地图服务、各种OA处理、工作流处理、人事处理、账簿处理、各种设备、甚至几百个ERP子系统的处理......”等等，因为你要将信息集成、捆绑在一起。
而客户端，则是千差万别的。例如你可以临时招聘3个winform程序员给某个企业开发一个20个并发终端规模的小的报价系统，也可以临时招聘3个wpf程序员给某个矿山开发一个200个终端的巡逻系统，或者招聘javascript程序员给40个城市开发一套银行某业务对账系统。等等。这些系统，不管是winform、wpf、silverlight、jaavscript甚至flash，都可以访问同一套c/s系统的服务器端。而这个服务器端可能需要有10台业务服务器、3台数据库服务器，来保证任何时候有2台服务器坏掉的时候你的服务都不会停止。
一个c/s系统的c，可以通过各种形式部署。例如通过vs工具默认集成的clickonce方式，放到任何一个web服务器上供桌面端的应用程序自动进行版本更新；或者像javascript、silverlight、flash这种客户端则可以随便放到一个支持文件下载的web服务器上，支持任何时候都是最新的程序。
只知道c/s的客户端而自己不会设计c/s的Server，是不能设计一个服务系统的。你还是玩单机小程序。
------解决思路----------------------
SP123说的过于偏激，LZ你别太认真，SP123大多时候说话都很带刺，虽然有时候他说的有道理。
BS和CS没啥本质区别，都是通讯应用。我就说说我关于BS和CS的认识，当然只是从平时的应用角度来说。
BS程序因为客户端是浏览器，客户端基本都是脚本或者超文本，因此BS的程序更加依赖于浏览器的语言解释功能，比如BS程序就对浏览器的版本和浏览器的厂家有一点挑剔，有时候你会发现你写的代码在某些浏览器上根本没用。
浏览器程序目前市面上的大致分成两种，一种是快速显示的，但是这类浏览器一般情况下信息都展示的不是非常完成，部分特定的脚本无法执行，毕竟他没有严格的遵从脚本解析的顺序。一种是慢速显示的，这类浏览器可以完整显示脚本信息，但是他的慢就是客户很难接受的。
bs程序脚本针对慢，有了一些优化和新的技术，这些技术很强大，但是他们终于逃不过浏览器的性能局限。
相较于bs，我更喜欢cs，因为cs程序有着bs无法替代的优势，那就是显示更快，但是cs也有他的弊病，那就是客户端软件的部署问题，这涉及到客户端的更新、安装等。如果客户端软件安装在性能不好的机器上，你会发现你的维护苦难刚刚开始。
不过现在这个时代，随便哪台电脑，甚至移动终端都比N年前的电脑先进了太多，只要你好好的优化客户端程序的逻辑，那么你会发现客户端的硬件并不是一个会困扰你的问题。
再说vpn这种东西，他只是提供给你一个网络访问的许可。只要网络通了，那么软件的通讯就通了。
无论是cs还是bs的程序，他们的server端的规模都是根据你的应用范围而定的，如果你的客户群体只是几十到几百的小客户群体，这个时候，你非要去部署一个几百台服务器的服务群，完全是没用必要的。
比如我现在的工作环境，我就凭着自己的兴趣，给单位同事开发一些小型的软件应用，面对的最多500人，我觉得目前来说一台服务器就足够我使用了，因此我开发的server也就是一台服务器的模式，不是我不会开发服务器群的软件，都只是不同的设计思想而已，没用那个必要。
举个例子，比如一套库存管理系统，多家客户使用，用什么架构比较好？
B/S号称维护量少，那是对一个客户而言，维护好服务器，客户端不用维护了。但是多个客户，就需要给每个客户来升级服务器端，反而更麻烦。尤其对于中小企业来说，让他们维护一个服务器很难，没有这种专人。软件公司要维护，那么就需要一个一个服务器逐个维护；
另外，企业数据放在托管的服务器上，很多企业不放心，感觉不安全，他们更倾向于自己有个服务器。
所以我感觉C/S架构的应该更适应这种情况，给客户一个升级包就可以了。可以让客户端自己升级，服务器基本不需要做什么操作。
C/S架构如何通过互联网访问，是否可以使用VPN？不知道大家有没有这么使用的？有什么心得？欢迎大家都来讨论。。。
------解决思路----------------------
再看你对c/s软件的概念，可以发现你在c/s上则是更加缺少知识的。
c/s不是指“只会写一个单机程序去调用关系数据库的驱动（例如ADO.NET驱动)”功能。这绝不是真正的c/s。你这种所谓的c/s，必然纠结什么vpn概念，因为你还是需要让所有人都用相同的账号密码去随便增删改查远程的数据库，而又担心安全性。
实际上，安全性远不是问题的主要矛盾。一个c/s是既有c又有s部分的，也就是说，你自己应该设计开发业务服务器Server。而你连企业业务服务器都不会设计，谈何c/s架构呢？一个企业业务服务器，就好像暴雪的游戏服务器似地，甚至更复杂，因为它要将你提供给各个企业的服务一网打尽。例如你的服务器要提供“即时通讯、地图服务、各种OA处理、工作流处理、人事处理、账簿处理、各种设备、甚至几百个ERP子系统的处理......”等等，因为你要将信息集成、捆绑在一起。
而客户端，则是千差万别的。例如你可以临时招聘3个winform程序员给某个企业开发一个20个并发终端规模的小的报价系统，也可以临时招聘3个wpf程序员给某个矿山开发一个200个终端的巡逻系统，或者招聘javascript程序员给40个城市开发一套银行某业务对账系统。等等。这些系统，不管是winform、wpf、silverlight、jaavscript甚至flash，都可以访问同一套c/s系统的服务器端。而这个服务器端可能需要有10台业务服务器、3台数据库服务器，来保证任何时候有2台服务器坏掉的时候你的服务都不会停止。
一个c/s系统的c，可以通过各种形式部署。例如通过vs工具默认集成的clickonce方式，放到任何一个web服务器上供桌面端的应用程序自动进行版本更新；或者像javascript、silverlight、flash这种客户端则可以随便放到一个支持文件下载的web服务器上，支持任何时候都是最新的程序。
只知道c/s的客户端而自己不会设计c/s的Server，是不能设计一个服务系统的。你还是玩单机小程序。
------解决思路----------------------
SP123说的过于偏激，LZ你别太认真，SP123大多时候说话都很带刺，虽然有时候他说的有道理。
BS和CS没啥本质区别，都是通讯应用。我就说说我关于BS和CS的认识，当然只是从平时的应用角度来说。
BS程序因为客户端是浏览器，客户端基本都是脚本或者超文本，因此BS的程序更加依赖于浏览器的语言解释功能，比如BS程序就对浏览器的版本和浏览器的厂家有一点挑剔，有时候你会发现你写的代码在某些浏览器上根本没用。
浏览器程序目前市面上的大致分成两种，一种是快速显示的，但是这类浏览器一般情况下信息都展示的不是非常完成，部分特定的脚本无法执行，毕竟他没有严格的遵从脚本解析的顺序。一种是慢速显示的，这类浏览器可以完整显示脚本信息，但是他的慢就是客户很难接受的。
bs程序脚本针对慢，有了一些优化和新的技术，这些技术很强大，但是他们终于逃不过浏览器的性能局限。
相较于bs，我更喜欢cs，因为cs程序有着bs无法替代的优势，那就是显示更快，但是cs也有他的弊病，那就是客户端软件的部署问题，这涉及到客户端的更新、安装等。如果客户端软件安装在性能不好的机器上，你会发现你的维护苦难刚刚开始。
不过现在这个时代，随便哪台电脑，甚至移动终端都比N年前的电脑先进了太多，只要你好好的优化客户端程序的逻辑，那么你会发现客户端的硬件并不是一个会困扰你的问题。
再说vpn这种东西，他只是提供给你一个网络访问的许可。只要网络通了，那么软件的通讯就通了。
无论是cs还是bs的程序，他们的server端的规模都是根据你的应用范围而定的，如果你的客户群体只是几十到几百的小客户群体，这个时候，你非要去部署一个几百台服务器的服务群，完全是没用必要的。
比如我现在的工作环境，我就凭着自己的兴趣，给单位同事开发一些小型的软件应用，面对的最多500人，我觉得目前来说一台服务器就足够我使用了，因此我开发的server也就是一台服务器的模式，不是我不会开发服务器群的软件，都只是不同的设计思想而已，没用那个必要。