基于业务单元的开发与部署模式-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

基于业务单元的开发与部署模式

简介:

许多的人注重开发效率,但是老鸟们不仅关注开发效率,更关注维护与技术支持效率,因为他们深深知道,一个有生命力的产品,维护与技术支持成本占整个产品开发运维成本的70%以上,也就是说开发成本只占不到30%的成本。

对于一个传统的MIS系统来说,别的不说,光数据库表结构的维护脚本就够受的了,设你的用户有几十家,或上百家,他们使用的版本可能是1.0到m.n中间的任何一个版本,设总共有x个版本。

这个时候一般有两种升级方法,一种是每做一个版本,就编写从前面任意一个版本到当前版本的升级脚本,这样脚本就有x套脚本,还要进行测试,如果这个时候还要跨数据库,比如:mysql,oracle,ms sql,informix,sybase,...,开发人员和测试人员无法承受之重,所以,按这种方法,工作量是越来越大,包袱越来越重。

那就说第二种方法,就是每次只做从上一个版本到当前版本的升级脚本。这种情况下,开发成本,测试成本可以相对得到较好的控制,但是升级的时候,就很麻烦了,需要识别当前用户的是哪个版本,然后再一个一个版本升上来,如果有自动化升级工具还好,如果没有的话,现场支持人员估计够受的,中间只出出现一点问题,可能就不知道后续应该如何处理了。

上面只说了数据库脚本,那么再说说程序,一般来说有个主线,还会有许多分支,根本不同用户购买的License不同,可能集成的内容也不一定相同,如果再有一些客户化开发,这里带来的问题,比数据脚本带来的问题还复杂。

曾经看到过某一团队,开发了一个系统,全在一个war工程中,结果就是开发效率低下,测试调试困难,没有人对整个系统全部熟悉。所以最后开发维护都无法维系,后续扩展无法继续,等待的结果就是一个,什么时候没有人能坚持的时候,它就可以死掉了。

所以,Tiny框架在设计之初,就在深入的思考这个问题。为此提出了业务单元的概念,就是把一个相对独立的模块合并为一个业务单元,一个业务单元包含了所以服务及界面展现以及数据初始化,数据库结构的各种资源及程序文件。

当然,业务单元也可以依赖其它的业务单元,如此就可以构建更大的系统及平台。在程序运行时,框架会读取BU中的数据库定义,初始化数据,等等,然后进行处理,保证不需要人工干预,就可以正确的运行。

这个时候,就实就引入了一个相当严重的问题,就是这些文件包含js,css,class,各种配置文件等等都放在java包,程序是怎么访问到它们的呢??为此我们做深入的扩展,使得各种资源都可以分散到jar包文件中,由此才得以实现模块化的需求。实际上模块化的想法很早就有,但是一直没有落地,就是因为资源文件方面的问题无法解决。

因此,解决了数据库初始化,菜单初始化,程序分解与集成等各种问题,程序员们要做的事情就是:我只要保证自己运行是正确的,整个系统就是运行正确的。不会因为是开发期、维护期,版本数多少影响到工作量。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章