编辑“B/S”（章节）

==B/S架构软件==
===维护和升级===
目前，软件系统的改进和升级越来越频繁，C/S系统的各部分模块中有一部分改变，就要关联到其它模块的变动，使[[系统升级]]成本比较大。

B/S与C/S处理模式相比，则大大简化了客户端，只要客户端机器能上网就可以。对于B/S而言，开发、维护等几乎所有工作也都集中在服务器端，当企业对网络应用进行升级时，只需更新服务器端的软件就可以，这减轻了异地用户系统维护与升级的成本。

如果客户端的软件系统升级比较频繁，那么B/S架构的产品优势明显——所有的 升级操作只需要针对服务器进行，这对那些点多面广的应用是很有价值的，例如一些招聘网站就需要采用B/S模式，客户端分散，且应用简单，只需要进行简单的浏览和少量信息的[[录入]]。 　　
===系统的性能===
在[[系统]]的性能方面，B/S占有优势的是其异地浏览和[[信息采集]]的灵活性。任何时间、任何地点、任何系统，只要可以使用[[浏览器]]上网，就可以使用B/S系统的终端。不过，采用B/S结构，客户端只能完成[[浏览]]、[[查询]]、数据输入等简单功能，绝大部分工作由[[服务器]]承担，这使得服务器的负担很重。采用C/S结构时，[[客户端]]和服务器端都能够处理任务，这虽然对客户机的要求较高，但因此可以减轻[[服务器]]的压力。

而且，由于客户端使用浏览器，使得网上发布的信息必须是以[[HTML]]格式为主，其它格式文件多半是以附件的形式存放。而[[HTML]]格式文件（也就是[[Web]]页面）不便于编辑修改，给文件管理带来了许多不便。比如说很多人每天上“新浪”网，只要安装了[[浏览器]]就可以了，并不需要了解“[[新浪]]”的服务器用的是什么[[操作系统]]，而事实上大部分[[网站]]确实没有使用[[windows]]操作系统，但用户的电脑本身安装的大部分是[[windows]]操作系统。 　　
===系统的开发===
B/S结构是建立在中间件产品基础之上的，要求应用开发者自己去处理事务管理、消息队列、数据的复制和同步、通信安全等系统级的问题。这对应用开发者提出了较高的要求，而且迫使应用开发者投入很多精力来解决[[应用程序]]以外的问题。这使得[[应用程序]]的维护、移植和互操作变得复杂。　
===B/S、C/S结构软件技术上的比较===
*无论是B/S还是[[C/S]]，他们都不新鲜。[[C/S]](Client/Server，客户端/服务器)技术从上世纪90年代初出现至今已经相当成熟，并得到了非常广泛的应用，其结构经历了二层C/S、三层C/S的更迭。B/S(Browser/Server，浏览器/服务器)技术则是伴随着[[Internet]]的普及而来的。有必要说明的是，B/S最早并不叫“B/S”，此类应用国外通常叫[[Web应用]]，是国内一些公司“创造”了“B/S”这个词。 　
*B/S和C/S各有千秋，他们都是当前非常重要的计算架构。在适用[[Internet]]、维护工作量等方面，B/S比C/S要强得多；但在运行速度、数据安全、人机交互等方面，B/S远不如C/S。综合起来可以发现，凡是C/S的强项，便是B/S的弱项，反之亦然。因此，问题也就因此而产生了，我们的ERP产品到底该用B/S还是C/S架构呢？一场关于C/S与B/S的口水战也由此在ERP业界拉开了序幕。在互联网泡沫盛行的2000年至2002年间，这场口水战达到了顶峰。但直到现在，人们也没有辩出谁是谁非。 　　
*事实上，从上面的分析可以看出，这场口水战不可能有胜负出现，因为B/S与C/S具有不同的优势与特点，他们无法相互取代。例如，对于以浏览为主、录入简单的应用程序，B/S技术有很大的优势，现在全球铺天盖地的Web网站就是明证；而对于交互复杂的ERP等企业级应用，B/S则很难胜任，从全球范围看，成熟的ERP产品大多采用二层或三层C/S架构，B/S的ERP产品并不多见。 　　
*“B/S还是C/S”也就由此成了ERP的技术之痛。难道这个痛就无药可救了吗？是否有可能将B/S与C/S的优势融合呢？答案是肯定的，在这几年的发展中将B/S与C/S的优势完美地结合起来，就是说该平台的应用系统能以B/S的方式发布运行，同时又具有C/S方式的极强的可操作性。这点从该平台生成的商品化的网络协同商务管理软件上得到充分的体现！