插件契约介绍
我们知道,要基于平台(容器)加插件的这种模式进行开发,我们必须定义一组契约,用于约束模块插件开发,也就是说,模块插件需要遵守一定的标准进行开发,才能正常被容器调用,这就是IModule所定义的内容。
IModule
IModule定义了模块名称及模块被调用的方法Run(),以及被平台加载和关闭的事件,从定义可我们看到IModule继续自IPrivilegObject。
IPrivilegObject
IPrivilegObject为权限对象接品,平台(运行容器)可以使用其鉴权系统对其实现权限检查,关于系统的权限设计我会在后面专门进行说明。
在模块插件的接口中,我们看到了很多关于模块自描述的信息,比如名称、说明、类型、程序集、版本号以及开发者等等,定义这些信息的目的在于对模块的自描述,资源管理平台在安装模块的过程中读取这些元数据并存储在数据库,以方便对系统中插件的管理。
模块元数据中定义的程序集、类型信息用于容器反射调用插件,这也是平台+插件所依赖的关键技术。
直接实现IMobile接口
开发人员可以选择直接实现IModule接口极其相关成员以实现一个业务插件,下面来一个简单的实现:
Calculator
原则说上,这种方法是可以的,但是在具体开发过程中,非必要情况下,不必要直接实现IModule接口,AgileEAS.NET平台提供了一组默认的基础实现。
复用AgileEAS.NET平台基础实现
开发人员直接实现IModule接口的问题在于会写大量与业务无关的代码,鉴于此问题,AgileEAS.NET平台针对WebForm和WinForm应用提供了一系统的基础实现,开发人员选择在合适的基类上继承并重写与业务相关的信息,下面是一个简单例子:
UserControl2
可以看到,代码相比直接实现IModule接口要简介的多,AgileEAS.NET提供了如下的默认实现:
EAS.Windows.UI.Forms.ModuleForm
WinForm模块插件的基类实现(独立的运行窗体),开发人员重写ModuleName、Description、Guid属性及入口方法Run即可。
EAS.Windows.UI.Controls.ModuleControl
WinForm模块插件的基类实现(内嵌入运行容器的业务控件),开发人员重写ModuleName、Description、Guid属性及入口方Run法即可。
EAS.Windows.UI.Controls.ExplorerControl
WinForm模块插件的基类实现(内嵌入运行容器的业务控件),相比较EAS.Windows.UI.Controls.ModuleControl提供了Close方法等、消息通知等增强功能,在开发过程中一般直接取代EAS.Windows.UI.Controls.ModuleControl。
EAS.Web.UI.ModulePage
WebForm模块插件的基类实现(独立的运行面),开发人员重写ModuleName、Description、Guid属性即可,WebForm插件因为其特殊性无需处理入口方法。
EAS.Windows.UI.Controls.ModuleControl
WebForm模块插件的基类实现(内嵌入运行容器的业务控件),开发人员重写ModuleName、Description、Guid属性即可。
别外,针对项目中大量的数据绑带应用业务,AgileEAS.NET平台配合数据绑定接口IDataBind也提供了如下基础实现:
EAS.Windows.UI.Data.Form、EAS.Windows.UI.Data.ModuleForm、EAS.Windows.UI.Data.Control、EAS.Windows.UI.Data.ExplorerControl。
EAS.Web.UI.Data.Page、EAS.Windows.Web.Data.ModulePage、EAS.Web.UI.Data.Control、EAS.Windows.Web.Data.ModuleControl。
AgileEAS.NET除了提供这一系列的基础实现之外,还提供了基于WinForm和WebForm开发常用的一组基础实现指导组件,称为GUI模板(EAS.Windows.Template.Dll和EAS.Web.Template.Dll)在开发中利于GUI能极大的加速应用开发,GUI模板以源代码的形式向开发人员提供。
属性标记Module
前面的1,2,3节都是基于实现IModule接口的方式来开发插件,下面将提供实现插件的另一种方式,利用.NET的声明编程的方式采用属性标记插件。
我们定义了ModuleAttribute属性:
ModuleAttribute
及ModuleRunAttribute/ModuleStartAttribute属性
ModuleStartAttribute
我们只需要在我们要公共的模块插件的类打上ModuleAttributes标记、在模块的入口调用方法上打上ModuleRunAttribute就可以了,以下为示例:
Hello
在以上例子中,我们标记了一个模块插件,他的GUID属性为“CB58C5BB-5D15-4a17-802E-341F9F65F35C”,模块名称为Hello例子,入口方法为Start方法,特别声明一下,Start必须为一公共为参该当,Web模块不需要入口方法。
关于IModule.Run的参数
通常情况运行容器是通过调用IModule接口的Run(params object [] parameters)方法实现功能模块的加载和运行,运行容器通过Run方法向功能模块以下参数。
第一个参数:模块插件的父容器,如果是模块为IModule接口,则这个参数为资源管理平台的主界面(Shell); 如果是模块为IExplorerControl接口,则这个参数为IExplorerControl模块的容器控IExplorerControlContainer实例。
第二个参数:为当前登录到资源管理平台的当前账号(EAS.Explorer.Users.IAccount Account)信息,提供系统当前使用者的信息。
第三个参数:为当前应用程序的会话信息,提供应用程序会话上下文环境,系统会话中包含着数据连接等相关的会话资源,模块程序也可以使用这些。第二个参数与第三个参数是相互的,第二个参数的Session属性就是第三个参数,第三个参数的Client属性就是第二个参数,意思就是说,会话建立在当前账号登录到系统上的这个操作形成的,而会话的客户端正是登前操作者。
功能模块在处理Run(params object [] parameters)方法时,可参考以下代码:
IExplorerControl:
public override void Run(params object[] parameters)
{
ISession session = (EAS.Sessions.ISession)parameters[2];
…
}
IModule:
public override void Run(params object[] parameters)
{
Form shell = (System.Windows.Forms.Form)parameters[1];
ISession session = (EAS.Sessions.ISession)parameters[2];
…
}
平台与模块的交互
我们知道,插件开发完成之后要安装、部署在平台中,运行在AgileEAS.NET平台的容器中,插件在运行过程中,如果取得平台的上下文参数,如当前系统的登录账户、数据库连接等一系列的插件运行资源。
在AgileEAS.NET平台的3.5版本之前,插件只有通过实现IModule接口来完成,所以平台与插件的交互也就通过Run方法来完成,Run方法提供了平台的三个参数,详细内容见2.5节。但是在3.5之后,AgileEAS.NET平台增加了更为方便的属性标记实现,对于模块的入口使用ModuleRun标记并且要求开发人员所标记的入口方法为无参方法,这样就无法通过插件入口的调用完成平台的参数传递。
为解决此问题,我们引入了一个上下文的概念,AgileEAS.NET平台上下文环境,在4.0版本后,我们建议即使通过IModule接口实现的模块,也不要使用Run入口方法的参数,转而使用AgileEAS.NET运行容器上下文环境:
EAS.Modularization.Platform.IContainer,提供了会话,上下文环境的定义,他的定义:
IContainer
通过接口定义我们可以知道,他提供了当前系统的账户、会话、应用程序上下文环境(IOC容器)、会话上下文环境等等。
在当前会话中定义了当前系统的各种会话资源如数据库连接、ORM访问器等等开发基础资料,程序员可以通过
IConnection dncn = Session.Resouces.FindResources(typeof(IConnection))[0] as IConnection;
的方式进行取得各种资源进行业务处理。
插件的调试
在最初的AgileEAS.NET平台版本中,是没有调试环境的,大概在2.0版本中加入了调试环境,WinForm的开发有独立的调试环境,WebForm的开发使用WebForm的运行容器直接调试:
WinForm应用开发中,提供了一个EAS.Develop.Debuger.dll的程序集,由它给我们的插件提供一个模拟的WinForm运行容器,怎么使用这个调试环境呢,首先在应用开发的VS解决方案中,增加一个新的应用程序项目AppStart,引用及其甩依赖的程序集,添加一个Start类并增加如下代码:
/// <summary> /// 调试器启动类。 /// </summary> class AppStart { /// <summary> /// AgileEAS.NET调试器入口。 /// </summary> [STAThread] static void Main() { EAS.Develop.Debuger.Application.Start(); } }
并修改配置文件中的Assembly配置项的值为需要调试的程序集名称:
<ConfigurationItem name="Assembly" value="EAS.Windows.FullExam"/>:
插件调试环境使用与真实运行环境的配置文件,同样的会话、同样的上下文环境,同样的系统会话资源,这一切都由系统配置文件进行配置。
链接
QQ群:116773358
作者:魏琼东
出处:http://www.cnblogs.com/eastjade
关于作者:有13年的软件从业经历,专注于中小软件企业软件开发过程研究,通过在技术与管理帮助中小软件企业实现技术层面开源节流的目的。熟悉需求分析、企业架构、项目管理。现主要从事基于AgileEAS.NET平台的技术咨询工作,主要服务于医疗卫生、铁路、电信、物流、物联网、制造、零售等行业。如有问题或建议,请多多赐教!
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,如有问题,可以通过mail.james@qq.com 联系我,也可以加入QQ群:113723486、199463175、116773358、116773358、212867943、147168308、59827496、193486983、15118502和大家共同讨论,非常感谢。
本文转自魏琼东博客园博客,原文链接:http://www.cnblogs.com/eastjade/archive/2010/09/13/1824708.html,如需转载请自行联系原作者