CSDN博客

img wonder365x

数据总线-平台的灵魂

发表于2004/6/30 14:53:00  861人阅读

用C开发程序比较多的人,对函数肯定是又爱又恨:作为过程语言,函数提高了程序的调理性,利于重用维护;编程中函数的参数又让人有些恶心,如果参数很多, 要写很长的参数列表,改动起来还得时刻准备加长,(如一个验证函数,一开始只有两个参数姓名、密码,后来又要扩充上权限),C语言中的函数声明又不和定义 部分在一起,实在麻烦。参数少的时候,还可以忍受,多的时候(如将接收前台数据传到子函数中)就难以忍受。所以有些时候会写一个超级长的函数来避免向子函 数传递参数。然而这样写出来的代码可维护性极其差(试问有几个程序员对几千行代码的长函数不头痛)。
实际上解决办法是有的,并且很普通,只是要增加额外代码。用中间件Tuxedo的fml(32)方式进行过开发的都知道,Tuxedo维护了一个大的缓冲 区,程序员可以通过变量ID去取得、更改其中的值。从前台传到后台的是一个指针(缓冲区),在大部分后台函数中只需传递指向缓冲区的指针这一个参数。进而 推展开,如果把这个缓冲区声明成全局的,并且加上一定的封装,最终程序员不需要在看到可爱又可恨的指针是多幸福的事情。诚然,这样会产生一些其它问题(后 边描述),但是程序的结构性,可读行大大提高了。如果可能,前后台都采用这种方式,数据透明的传输,一般的开发人员不用再关心什么中间件、指针之类的东 西,只要知道名字(如“操作员姓名”)就可以找到、更改对应的值。前台程序中不必再写从这个form上某个edit控件取出值,转换为后台需要的形式,组 织后台程序需要的信息流;后台程序中不必把指针指来指去该是多么幸福的事情。
just one name.
对,只要一个名字。如果信息流的格式发生改变,如由fml改为xml只需要改动格式生成规则,快捷方便。这里是以tuxedo为例子,实际上如果提供一个 平台完成这些,根本不需要考虑具体的实现形式(牛人可以自己写一个类似的缓冲区管理库),还有其它一些好处,不再一一列举。
当然会存在一些问题:

   1. 命名混乱。不同模块、函数中变量命名一定要控制住,否则会产生与过多使用全局变量同样的问题,不是变量找不到,就是变量乱使用,总而言之,变量混乱。
   2. 缺少访问控制。数据总线相当于全局变量,任意的函数都能访问到其中的变量,如果无意中更改了,会产生莫名其妙的错误。
   3. 效率会降低。当前的硬件可以忍受这些损耗。

初步的解决设想:
增加访问控制,数据总线分为程序级和交易级,程序级在本进程中始终不释放,交易级总线只在一个小的交易模块中作用。如果可能,在函数访问前可以lock一些变量,减少损失。
相关问题参见blog中其它文章

0 0

相关博文

我的热门文章

img
取 消
img