成为技术老大技术管理篇5一技术演变史(3)

发表于:2018-5-08 09:55  作者:铁棍山药   来源:简书

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试技术 测试团队

  上一篇我们说到了,早年单机程序最麻烦的事情就是绘制控件,把界面做美观不容易。当时上网还需要拨号,而且费用昂贵,互联网的基础设施还没有完善。主流的软件公司都在为企业开发软件。
  企业软件一般都要多人来使用,所以就催生了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界面绘制的复杂度,下一篇我们再聊。

相关文章
成为技术老大技术管理篇1一技术管理管理什么
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

【直播预售】接口测试行业大佬带你从青铜上王者>>立即查看

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2018, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道