[mBean]的萌芽
最近公司要求把我们公司的任务可以外包,问我有没有好的方案。
如果要其他程序员的人来做我们内部的框架会导致了,内部的框架需要公布很多单元和逻辑,思路。其次要把我们的思路和规则强加给其他的程序员。加大了其他人员的上手难度。
带着这种问题把框架又进行了新一轮的优化。每每改进框架后都想丢弃掉之前的框架。心里安慰自己应该是思想上得到了升华。确实从最初的框架到mBean得到了很大的提升,从之前的带[shareCentre.bpl]到现在的[mBean]编写插件规则越来越领活,前一版本的框架要求都实现IPlugin,IPlugin里面定义了一些方法。[mBean]框架中插件只要求实现[IInterface]就可以成为插件。逻辑插件不要求语言,不要求带包。只要实现了接口都可以调用。现在想这应该是我终极版的的框架了……。以后只会在框架上面开发更多实用的接口了。
[mBean]的优点
不用带特定的bpl,就可以是插件,远离提示包需要进行编译的痛苦。
可以导出接口的dll都可以是制作插件。
不用带特定的bpl进行对象的共享。
不光是窗体才是插件,panel也可以是插件,TFrame也可以是插件。一个简单逻辑也可以是个插件。
干预代码最少,beanFactory.registerBean("xxx",Txxx);就可以注册插件。
可以将插件注册车单实例插件。怎么获取都只会创建一份beanFactory.registerBean('xxxx',TXXx).isSingleton := true;
获取方便,app.getBean("xxx"),就可以创建一个插件不用管插件在哪个DLL中。
绿色小巧,不用安装任何dpk,和ocx。
支持各种版本D(D7-XE5)。
[红色区域是不带包的DLL中的插件窗体]
[mBean]的来源
为什么JAVA比Delphi使用的人多,想想,JAVA模式比较固定,比如WEB有成熟的SSH框架和解决方案,让初学者容易上手,代码比较规范,相反Delphi开源东西太少,门派太多,门道太深,太多。
[mBean]借鉴Spring模式Bean模式,来管理插件。
[mBean]插件不限定编写模式,不限定继承关系,不强制带包。以一种包容心态来接收插件。
[mBean]的插件编写
在DLL中像beanFactory注册插件,插件对象实现IInterface就行了,编译出来的dll放到plug-ins目录下面就可以被beanManager.dll进行管理和调用。
调用时 appPluginContext.getBean('frameScript') 就可以返回一个接口,进行使用。
[mBean]的扩展协议
每个公司都有自己的主窗体模式,
有的主窗体要求子窗体嵌入tabSheet上面,
有的要求子窗体是mdi模式
每个软件开发公司都是 自己的方案和设计。
可以制度相应的协议和接口,来管理主窗体和子窗体直接的关系。
比如:
要求主窗体实现如下接口:
type IMainForm = interface(IInterface) ['{69DDA539-DF48-441A-9149-229BF17C8E78}'] procedure closeQuery(const pvForm: IInterface; vCanClose: Boolean); stdcall; function Remove(const pvInstanceID: Integer): boolean; stdcall; procedure openModuleAsMDI(pvModuleFuncIndex:Integer); stdcall; procedure openModule(pvModuleFuncIndex:Integer); stdcall; end;
要求子窗体实现如下接口:
type /// <summary> /// 窗体插件 /// </summary> IUIForm = interface(IInterface) ['{7E250C3C-331E-4732-AD05-F08CA1CA486A}'] procedure showAsMDI; stdcall; function showAsModal: Integer; stdcall; //关闭 procedure UIFormClose; stdcall; //释放窗体 procedure UIFormFree; stdcall; //获取窗体对象 function getObject:TObject; stdcall; //获取实例ID function getInstanceID: Integer; stdcall; end;
这些协议可以自己去定义,并去实现和遵守,这样就是[mBean]协议的扩展。
D2007, XE5进行过编译
[mBean]下载