上面是插件接口的定义(与上一节的,略有不同),这样的定义具有通用性,我们定义的原则就是不能有任何特定于某个插件的东西.
原来我是想使用这样的架构思想来构建一个完全由插件构成的软件,如同eclipse,但是发现这样的想法有点空中楼阁的感觉,为什么这样说呢?我来举个例子:
我们设想这样的一个系统,它打开数据库,并打开一个表,修改记录并提交更新.这是一个数据库系统最基本的应用.
容器的工作大概情况是这样:
从Database.bpl得到一个adoConnection,
传入adoConnection参数给OpenQuery.bpl,并得到返回数据TClientDataset;
传入这个TClientDataset参数给ProcessData.bpl,它将数据载入界面并显示给用户,执行完毕后,容器会得到一个Delta封包,包含了用户所做的更新.
将该Delta封包参数和adoConnection参数传递给UpdateData.bpl,由它做数据库的更新.
传入adoConnection参数给OpenQuery.bpl,并得到返回数据TClientDataset;
传入这个TClientDataset参数给ProcessData.bpl,它将数据载入界面并显示给用户,执行完毕后,容器会得到一个Delta封包,包含了用户所做的更新.
将该Delta封包参数和adoConnection参数传递给UpdateData.bpl,由它做数据库的更新.
传入adoConnection参数给OpenQuery.bpl,并得到返回数据TClientDataset;
传入这个TClientDataset参数给ProcessData.bpl,它将数据载入界面并显示给用户,执行完毕后,容器会得到一个Delta封包,包含了用户所做的更新.
将该Delta封包参数和adoConnection参数传递给UpdateData.bpl,由它做数据库的更新.
传入adoConnection参数给OpenQuery.bpl,并得到返回数据TClientDataset;
传入这个TClientDataset参数给ProcessData.bpl,它将数据载入界面并显示给用户,执行完毕后,容器会得到一个Delta封包,包含了用户所做的更新.
将该Delta封包参数和adoConnection参数传递给UpdateData.bpl,由它做数据库的更新.
容器负责了整个工作的调度,它完全采用插件来完成每一步工作,我们可以实现不同的bpl来替换其中的相应角色,例如:
使用Database4SqlServer.bpl来提供对另一个数据库的访问(当然这可以使用不同的connectionString达到同样的效果,而且更简单,这里只是为了说明)
使用ProcessDataByRzLib.bpl来给用户呈现不同的界面控件
使用UpdateDataAndLog.bpl来更新数据,使在更新数据的同时写入日志
而我们的容器不需要做任何的更改,它只明白,需要4个不同的类可以完成工作,而各个角色如何来完成角色工作,他并不关心,它能驱动这些类,让系统运转起来.
这样的系统看起来已经很不错了,但是容器本身必须知道自己要干什么,必须知道如何组织载入的插件,以及它们的调用顺序,数据如何通过容器做为中转在插件之间交互.我们可不可以让容器也被什么东西来驱动起来呢?或者说容器的行为能够被配置起来,由外部来告知容器,这样容器本身就具有了可移植性.
有关面向接口编程
面向接口编程意味着系统中由一个管理程序,它组织许多的接