基于OEA框架的客户化设计（一） 总体设计
这篇文章还是对工作内容的总结，主要是总结一下这几天做的产品的客户化工作内容。
关于产品线工程中客户化的理论知识和概念，请见金根的《产品线工程》。具体的，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"/>
限于篇幅，今天就先总结到此。下一篇主要是把客户化框架的设计讲完，然后再下一篇可能是GIX4项目中分离原有DLL的应用。
