技术管理篇5一技术演变史(3)

上一篇我们说到了，早年单机程序最麻烦的事情就是绘制控件，把界面做美观不容易。当时上网还需要拨号，而且费用昂贵，互联网的基础设施还没有完善。主流的软件公司都在为企业开发软件。

企业软件一般都要多人来使用，所以就催生了C/S架构的诞生。早先就是单机客户端访问一个共同的数据库，这样就做到了所有人数据的共享。

C/S架构首先碰到的问题就是不同生产商数据库的访问问题，不解决这个问题，单机客户端早晚就得耦合各种数据库的特殊代码。说个题外话，大家可能觉得用一个单一数据库不就没问题了，但是现实场景中，企业的采购会尽量避免单一化，如果你做的软件想迎合大多数客户，这个问题还真就是个问题。这可能也是企业软件和互联网软件业务需求的很大不同。

解决这个问题的主流方案有两个，分别是ODBC和JDBC。其实两者都采用了Driver驱动模式。驱动模式很简单，其实就是面向对象的接口编程思想。先约定一个接口，然后各家厂商给出实现。系统具体访问数据库的时候，根据配置信息来装载不同的实现，我们访问数据库只需要跟这个接口打交道就好了。

我们可以看到，很多领域都采用了类似的模式，比如我们用的Window系统经常就会碰到要装驱动，只要符合PCI接口的外设，操作系统装载这个设备的驱动后就可以使用。再比如Spring框架中的IOC，也是同样的效果。我们只需要针对接口编程，不用关心具体实现方案。

针对C/S软件的IDE有不少，PowerBuilder应该是当时最流行的工具之一吧。UI组件丰富，设计器拖拽生成界面，而且跟数据库的数据结合自然，事件驱动脚本代码，学习成本极低。坦率的讲，PB是到目前为止，我接触过最易用的IDE之一。

看起来C/S架构软件也还不错，能满足用户需求，也有很好的IDE支撑，界面体验也足够好。但是，C/S架构的软件有一个天然的问题，就是逻辑代码都在客户端，迭代升级都需要用户重新安装，非常麻烦。

为了解决这个问题，大家想了各种方法。我们可以把客户端的业务代码抽取出来，用数据库的存储过程实现。这样客户端就只剩下界面展示和控制代码。实际到今天为止，在企业旧的系统中，还能看到这个方案残存的影子。

这个方案有什么缺点呢，第一，各厂商数据库存储过程标准并不统一，切换数据库非常麻烦；第二，客户端虽然只剩下界面展示代码，但是更新仍然很频繁；解决问题一，就需要我们在客户端和数据库之间再加一层，把业务逻辑从存储过程中抽离出来，这样数据库就只负责数据存储和查询，切换变得简单；解决问题二，如果客户端展示逻辑也能由服务器端下发，客户端变为很薄的运行层是否就能解决。如果这个展示逻辑统一为Html标准，运行层统一为浏览器，大家看一下，这是不是就是B/S的基本框架。

B/S架构能有效解决C/S架构出现的问题，而且随着互联网基础设施的逐步完善，软件从服务企业内部客户，逐渐变为服务大众用户。普通大众对软件的可用性和易用性要求会更高，给普罗大众安装客户端变得极其困难，另外数据量越来越多，单台数据库也无法支撑。这一切的变化，使得C/S架构逐渐退出了历史舞台。

C/S架构虽然逐渐不再采用，但是基于UI组件的事件开发模式深入人心，一直以来，各种方案层出不穷，期望用组件化抹平B/S界面绘制的复杂度，下一篇我们再聊。