印象中的Package在一般的AP开发时,我们知道在Delphi7.0整合环境中将Project->Options->选到Packages卷标页,Builder with runtime packages选项打勾,就会让编译出来的执行文件Size变小很多(以空白的Form1为例,编译出来的Size由367kb变成20kb),因为它把一些VCL共享模块的Loding放到*.bpl中;换句话说这个变小的EXE文件在执行时是需要那些*.bpl的,而原本较大的执行文件执行时则不需要那些*.bpl,这样看来其实只是换汤不换药罢了。
这种编译架构的差异有什么优点?试想,如果Project1.exe&Project2.exe都不使用Builder with runtime packages选项,Project1.exe跟Project2.exe编译出来的Size都是367kb,若有10个ProjectN.exe,则占用的Size将是全部exe加起来的总和,若是我们将其****享的部分(如VCL共享模块)独立出来,每个EXE都将只有20K(以测试用的空白Form而言),缺点则只有每个exe执行时都要在系统搜寻路径中找得到那些VCL的共享模块(以*.bpl文件名存在);所以这种架构适用于一个项目系统内有多个独立执行文件或独立业务模块存在的情况,多个执行文件就可以分散给多个人去开发,也可依照应用程序不同的业务性质去区隔并分别设计。
将执行文件分散开来开发,这种做法跟一个主执行文件配合多个不同业务别的DLL开发没有什么差别,而降低每支执行文件的Size也只是Package最普通的应用 使用Package有一个更强大的优点——可以共享变量,如果将数据模块当成一个共享变量的观念去看待,我们不用在每次启动或关闭不同的子系统业务模块时,重新连接或释放数据库的Connection。不过,要真正能共享数据库模块是需要每个业务模块皆以*.bpl的方式存在,这也是实际应用上的状况。
项目架构种类 | Package编译方式 | 说明 |
类型一 Project0.exe(MIS主系统) Project1.exe(会计子系统) Project2.exe(人事子系统) Project3.exe(库存子系统) | 所有EXE文件编译选项 □Builder with runtime packages
| 1.每个子系统都是完整独立的EXE文件;每个EXE文件至少都有数百KB以上 |
类型二 Project0.exe(MIS主系统) Project1.exe(会计子系统) Project2.exe(人事子系统) Project3.exe(库存子系统) | VCL共享模块(*.bpl) 所有EXE文件编译选项 ■Builder with runtime packages(打勾)
| 1.每个子系统虽然都是EXE文件,但执行时需要VCL的共享模块存在;此种方式,每个EXE文件SIZE都只有几十KB 2.此种架构只有节省档案SIZE的优点 |
类型三 Project0.exe(MIS主系统) Project1.bpl(会计子系统) Project2.bpl(人事子系统) Project3.bpl(库存子系统) VCL共享模块(*.bpl) DataMoudle(db.bpl) | 所有EXE文件编译选项 ■Builder with runtime packages(打勾)
| 1.将各子系统****享的程序(如连接数据库的模块)独立出来共享 2.除主系统外其余子系统皆为BPL型式存在 3.节省档案SIZE外,并有共 用数据库连结模块的优点 |
注:
1.MIS主系统