求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
 
基于OEA框架的客户化设计 总体设计
 

2010-11-24 来源:网络

 

这篇文章还是对工作内容的总结,主要是总结一下这几天做的产品的

客户化工作内容。

关于产品线工程中客户化的理论知识和概念,请见金根的《产品线工程》。具体的,OEA框架中的客户化理论,见:《软件产品线工程方法:如何在OpenExpressApp做客户化工作》。

本文主要从以下几个方面来叙述如何在OEA框架中设计和实现客户化框架:

OEA客户化框架设计目标
方案设计
具体实现

--------------------------------------------------------------------------------

设计目标

支持实体类的扩展。
支持实体扩展包的动态加载。
支持界面扩展及界面扩展包的动态加载。
各版本间自定义界面元素,可以基于现有的特定版本修改一些内容。
各版本间支持自定义内容文件,如果没有使用,则使用默认版本的内容文件。(内容文件是指:图片、帮助文档等。)
解释一下,基于OEA框架的GIX4项目是以领域实体为中心的架构。主版本中的领域实体,代表了产品功能“7、2、1”中的7和2 。7是所有版本都应该有的领域实体,2是可以进行配置以说明是否具备的领域实体,而1就是在主干之外,为特定版本开发的实体。所以以上目标中,支持对“2”的定制和对“1”的扩展是最重要的。

由于时间仓促,目前只能以上述内容为目标,以后可能还会添加一些内容。如,枚举值的客户化,DailyBuild客户化等。

--------------------------------------------------------------------------------

方案设计

本次设计经过组内讨论,确定了具体的设计方向。这里主要对最重要的两项进行详细的叙述。

配置?

一般来说,要实现客户化,使用配置可能是最直接的想法。一开始我想也没想就觉得可能客户化的内容需要存储在配置文件中,可能是一个自定义的XML文档。但是,后来和朋友聊天过程中灵光一闪,真的要采用配置吗?这里根本不需要在运行时动态改变应用程序的行为,只要在编译期能够编译出不同的版本即可,所以我决定使用“应用程序定义”的方式来完成“配置”。而“定义”与配置不同点在于,定义是用代码写死的,程序运行期间不可更改。编译期根据定义编译不同的版本。

其实后来知道,产品线工程中的重点之一就是对产品的“可变性”进行管理。而可变性的实现机制有很多种,主要分三类:适配、替换、扩展,具体内容见:《软件产品线工程方法:如何在OpenExpressApp做客户化工作》。

设计之初,我认为客户化的应用程序配置应该满足:

可以有公共的配置,子配置如果设置了同样的项,则重写公共的配置。
简单可用的配置API
最后,我定出了以下的实现目标:

主干版本中有应用程序定义类ConfigMain,客户A和客户B分别有自定义的配置类ConfigA,ConfigB。

各客户的版本中,分别把他自己的配置类和主配置类结合,然后以配置文件的方式注入到整个应用程序中。

当应用程序读取某个配置项时,直接从注入的配置类中获取;此时,按照一定的寻找顺序,定位该配置项。如客户A的配置类为ConfigA + ConfigMain,则在寻找时,应该先在ConfigA中寻找,如果找不到,则在ConfigMain中寻找。

文件组织方式

各客户版本需要不同的文件来运行,这些文件主要是一些内容文件,如图片,xml,也包含少量的DLL。毫无疑问地,客户化工作需要对它们进行管理。

DLL文件的组织比较简单,只需要各客户版本把自己的DLL放在一个版本特定的目录下,程序动态加载就行了。

这里我定出了以下规则:所有需要客户化的DLL都放在客户各自的文件夹根目录下。

但是这里需要注意,这些代码文件需要在应用程序定义被加载之后,才会被应用程序加载。所以应用程序定义类需要被直接DI进来,这样,客户版本信息就可以在这些DLL加载之前被访问到,也就可以继续加载这些DLL了。

内容文件的组织不同于代码,这些文件很可能在运行时也需要被替换。所以这里的策略不能再使用“定义”的方式。需要有一定的文件寻址算法。以下是暂定方案:

所有需要客户化的文件都放在/Files/中。版本通用文件,则直接放在/Files/Common/中。各客户有自己的文件夹,如客户A有文件夹/Files/A/。文件夹名在配置类中标明。
程序中,可以文件寻找引擎指定要使用的文件的相对路径,如使用LOGO,则指定/Images/Logo.jpg。如果客户A在A中已经建立了/Files/A/Images/Logo.jpg文件,则返回此文件;否则返回的应该是/Files/Common/Images/Logo.jpg。

方案总结

使用定义而不使用配置的方式,防止了不必要的程序代码的开发。但是要注意定义的API的简便和易用性。

文件组织方式使得各客户文件完全分离,简化了Buid 版本的代码开发。这里主要注意路径寻址的实现。

--------------------------------------------------------------------------------

具体设计

应用程序定义类的实现

为支持属性值的重写和融合,应用程序定义类直接使用OO的继承实现,通用的定义类作为基类,分支版本直接从它派生下来并重写新的属性。使用OO的方式可以很好地实现属性值扩展,例如,我们可以使用装饰模式来实现复杂的属性定义。

应用程序定义类中,应该组合一些分支对象,来进行更细粒度的定义。

下图是本次客户化中应用程序定义类的结构:

图1 应用程序定义类的结构

Freeable表示所有定义都是可以被冻结的。这些定义在一开始被设置好版本的值后,将会被冻结,所以内容不再改变,变为“不可变类”。一,这是其运行期不需要改变的体现;二,不可变类是高效的类。

PathDefinition是所有内容文件的路径定义,它使用了PathProvider类来为其提供内容文件路径寻址算法,同时,它使用内容文件的相对路径从PathProvider中获取真实路径。

UIInfo是视图信息的载体,该类是定义的重点,留待下一篇中介绍。

AppDefinition是整个应用程序定义类的基类,以DI实现单例模式,作为全局唯一的访问点。目前,它包含了一个UIInfo对象来提供视图信息和一个PathDefinition来提供文件路径。

以下主要给出AppDefinition类具体的代码:

/// <summary>
/// 应用程序的主干版本定义。
/// 同时,也是分支版本定义的基类。
/// </summary>
public abstract class AppDefinition : Definition
{
#region SingleTon

private static AppDefinition _instance;

/// <summary>
/// 提供一个静态字段,作为全局唯一的访问地址。
/// 注意:本类并没有直接设计为单例模式!
/// </summary>
public static AppDefinition Instance
{
get
{
if (_instance == null) throw new InvalidOperationException("请先设置该属性。");
return _instance;
}
set
{
if (value == null) throw new ArgumentNullException("value");
if (_instance != null) throw new InvalidOperationException("该属性只能被设置一次。");
_instance = value;
}
}

#endregion

/// <summary>
/// 查找文件路径的查找算法提供器。
/// </summary>
private PathProvider _pathProvider;

/// <summary>
/// 在使用所有属性前,需要主动调用此方法来进行初始化。
/// </summary>
protected override void InitCore()
{
base.InitCore();

this.CheckUnFrozen();

this._pathProvider = new PathProvider();
if (!string.IsNullOrWhiteSpace(this.BranchAppName))
{
this._pathProvider.AddBranch(this.BranchAppName);
}

//初始化所有文件路径
this.Pathes = this.CreatePathes();
this.Pathes.SetPathProvider(this._pathProvider);
this.Pathes.Initialize();

//创建元数据库
this.UIInfo = this.DefineUI();
this.UIInfo.Initialize();
}

protected override void OnFrozen()
{
base.OnFrozen();

FreezeChildren(this.UIInfo, this.Pathes);
}

/// <summary>
/// 分支版本名。
/// 同时,这个也是客户化文件夹的名字。
/// 分支版本定义,需要重写这个属性。
/// </summary>
protected virtual string BranchAppName
{
get
{
return null;
}
}

#region 文件

/// <summary>
/// 创建所有路径的定义。
/// 子类重写此方法,用于添加更多的路径信息定义。
/// </summary>
/// <returns></returns>
protected virtual PathDefinition CreatePathes()
{
return new PathDefinition();
}

/// <summary>
/// 应用程序中所有使用到的需要客户化的路径集。
/// </summary>
public PathDefinition Pathes { get; private set; }

#endregion

#region DLL

/// <summary>
/// 获取所有此版本中需要加载的实体类Dll集合。
/// </summary>
/// <returns></returns>
public string[] GetEntityDlls()
{
return this._pathProvider.MapAllPathes("Library", true);
}

/// <summary>
/// 获取所有此版本中需要加载的模块Dll集合。
/// </summary>
/// <returns></returns>
public string[] GetModuleDlls()
{
return this._pathProvider.MapAllPathes("Module", false);
}

#endregion

#region UIInfo

/// <summary>
/// 应用程序中所有可用的视图信息。
/// </summary>
public UIInfo UIInfo { get; private set; }

/// <summary>
/// 子类重写此方法,用于初始化产品视图定义。
/// 重点实现!
/// </summary>
/// <returns></returns>
protected virtual UIInfo DefineUI()
{
return new UIInfo();
}

#endregion
}

子版本的定义需要重写父类的DefineUI方法进行自己的版本信息定义,如,通用版本的实现:

namespace Common.Definition
{
/// <summary>
/// 通用版本的产品定义
/// </summary>
public class AppDefinition : OpenExpressApp.MetaModel.Customizing.AppDefinition
{
/// <summary>
/// 子类重写此属性以指定是否包含合同。
/// </summary>
protected virtual bool IncludeContract
{
get
{
return true;
}
}

/// <summary>
/// 这里加入东方版本需要的特定的视图信息
/// </summary>
/// <returns></returns>
protected override UIInfo DefineUI()
{
var ui = base.DefineUI();

ui.Entity<CBFGQBQItemTitle>()
.EntityProperty(t => t.Code).ShowInLookup().ShowInList().Set_ListMinWidth(200);

ui.Entity<CBSummary>()
.EntityProperty(t => t.PBSId).Show().Set_ListMinWidth(500);

ui.Entity<CBNormSummary>()
.EntityProperty(t => t.PBSId).Show().Set_ListMinWidth(100);

//在基类上定义视图信息,这个类的所有子类如果没有显式设置其它的值,则会使用基类的属性。
ui.Entity(typeof(BQNormItemTitleBase))
.EntityProperty("AllCode").Show().Set_ListMinWidth(200);

this.DefineContractDll(ui);

return ui;
}

/// <summary>
/// 定义合同模块的显示。
/// </summary>
/// <param name="ui"></param>
private void DefineContractDll(UIInfo ui)
{
if (this.IncludeContract)
{
ui.Entity<ContractBudget>().UnVisible();
ui.Entity<RealContractBudget>().Visible();
ui.UnVisible(
CCN.ShowPCIBQitemCommand, CCN.EntityShowBQCommand,
CCN.MeasureShowBQCommand, CCN.ResourceShowBQCommand,
CCN.ProjectIndicatorsCalculationCommand
);
}
else
{
ui.UnVisible(
typeof(RealContractBudget), typeof(ContractSubjectType),
typeof(ProjectContractSubject), typeof(ContractIndicatorQueryObject)
);
ui.UnVisible(
CCCN.ShowPCIBQitemCommand, CCCN.EntityShowBQCommand,
CCCN.MeasureShowBQCommand, CCCN.ResourceShowBQCommand
);
}
}
}
}

程序在启动时,从配置中注入AppDefinition,然后调用其初始化操作和冻结方法即可:

public partial class App : Application
{
public App()
{
this.InitAppDefinition();
}

/// <summary>
/// 定义软件运行时版本
/// </summary>
private void InitAppDefinition()
{
var appDefType = Type.GetType(AppConfig.Instance.AppDefinitionClass, true, true);

AppDefinition.Instance = Activator.CreateInstance(appDefType) as AppDefinition;
AppDefinition.Instance.Initialize();
AppDefinition.Instance.Freeze();
}
配置文件:

<add key="AppDefinitionClass" value="Common.Definition.AppDefinition, Common.Definition"/>



专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS


面向应用的架构设计实践
单元测试+重构+设计模式
软件架构师—高级实践
软件架构设计方法、案例与实践
嵌入式软件架构设计—高级实践
SOA体系结构实践


锐安科技 软件架构设计方法
成都 嵌入式软件架构设计
上海汽车 嵌入式软件架构设计
北京 软件架构设计
上海 软件架构设计案例与实践
北京 架构设计方法案例与实践
深圳 架构设计方法案例与实践
嵌入式软件架构设计—高级实践
更多...