本篇博客记录了我在工作过程中的一个设计单元。
需求
GIX4项目中需要为非国标清单进行匹配，用户自定义匹配规则。规则可以被存储到数据库中，下次重复使用。界面原型如下：
图1 界面原型
用户可以指定对对象的某属性进行某个比较操作。
设计-总体结构
图2 总体结构
看上去会有点晕？懒了一点，就全画一起了。 :o)
中间的接口就是整个结构的核心所在，下面会详细解释：
第一组接口：设计匹配概念
首先，明确匹配的概念，这个概念是与GIX4应用无关的。 一个是可以被匹配的对象，另一个则是主动匹配者。如下：
/// <summary> /// 被匹配的对象 /// </summary> public interface IMatchTarget { } /// <summary> /// 可以实施匹配操作的类。 /// </summary> public interface IMatchable { /// <summary> /// 是否已经匹配过了。 /// </summary> bool HasMatched { get; } /// <summary> /// 开始匹配 /// </summary> /// <param name="target"></param> void Match(IMatchTarget target); }
第二组接口：设计过滤规则
动态规则是需要存储到数据库中的，但是由于它的形式十分灵活，所以这里选用XML这种半结构化的数据格式来存储规则内容，最后再序列化存储到数据库中。这种解决方法适用于一些小型的、结构变化性大的对象，如下：
/// <summary> /// 可以被序列化为XML内容的对象 /// </summary> public interface IXmlSerializable { /// <summary> /// 序列化为XML值。 /// </summary> /// <returns></returns> XElement Serialize(); } /// <summary> /// 过滤规则 /// </summary> public interface IFilterRule : IXmlSerializable { /// <summary> /// 判断某个可匹配对象是否符合规则。 /// </summary> /// <param name="source"></param> /// <returns></returns> bool IsMatch(IMatchable source); } /// <summary> /// 对IFilterRule序列化的结果进行反序列化。 /// </summary> public interface IFilterRuleDeserializer { /// <summary> /// 反序列化 /// </summary> /// <param name="element"></param> /// <returns></returns> IFilterRule Deserialize(XElement element); }
IFilterRule是这三个中最重要的接口。表示一个动态的过滤规则。在GIX4中，它可以是一个简单的规则：
“对象的Name属性应该包含‘***’”
也可以是由各种简单规则复合而成，如：
“对象的Name属性应该包含‘***’” AND “对象的Name属性应该满足正则表达式‘***’” AND “对象的Amount属性应该大于‘0’”
这里IFilterRule接口及其子类的设计方法，类型“表达式树”。（朋友说其实是解释器模式，不过我自己也没记住解释器模式是什么结构，所以不知道这里到底是不是。） :O)
第三组接口：元数据-比较操作
过滤的规则是动态的，但是对于某种数据类型（string、int）进行的比较操作，却是固定的。过滤规则则是由这些固定的操作组合而成。如：我可以对User对象的Name属性（string）进行是否以某字符串开头的判断，可以定义如下：Name BeginWith “王”，这里的BeginWith就是一个比较操作，它针对类型string。操作定义如下：
/// <summary> /// 比较操作 /// </summary> public interface ICompareOperation { /// <summary> /// 同类型下唯一的名字 /// </summary> string Name { get; } /// <summary> /// 判断两个值是否符合这个配对策略 /// </summary> /// <param name="sourceValue"></param> /// <param name="targetValue"></param> /// <returns></returns> bool IsMatch(object sourceValue, object targetValue); }
第三组接口：元数据-属性规则
由于项目中最常使用的就是根据属性的值来进行简单的过滤，所以定义了一个“可匹配属性”接口。通过它，可以获得能够对这个属性进行的所有操作。可以获取到指定的可匹配对象IMatchable的该属性值。实现时可以不使用反射而进行快速获取值，加快匹配速度。
/// <summary> /// 用于匹配操作的属性。 /// </summary> public interface IMatchableProperty { /// <summary> /// 属性名 /// </summary> string Name { get; } /// <summary> /// 用于显示的名字 /// </summary> string Label { get; } /// <summary> /// 属性所在的IMatchable类名 /// </summary> Type MatchableType { get; } /// <summary> /// 属性类型 /// </summary> Type PropertyType { get; } /// <summary> /// 允许的操作 /// </summary> IList<ICompareOperation> Operations { get; } /// <summary> /// 获取指定对象的值。 /// </summary> /// <param name="machable"></param> /// <returns></returns> object GetValue(IMatchable machable); } /// <summary> /// 匹配属性元数据工厂 /// </summary> public interface IMatchablePropertyFactory : IStringConverter { /// <summary> /// 根据匹配对象的类名，查询这个类所对应的用于匹配操作的所有属性。 /// </summary> /// <param name="matchableTypeName"></param> /// <returns></returns> IList<IMatchableProperty> GetProperties(string matchableTypeName); //IList<IMatchableProperty> Get(Type matchableType); }
到现在，最基本的接口就已经设计完成。
集成到GIX4
1.外观
模块使用外观模式构建Facade类来降低外部使用的复杂度。
2.组装
系统主要是匹配PBS到FGQBQItem。本着“新增优于修改”的原则，不想在原有的类上修改或者、添加新的代码，所以这里为这两个类分别扩充新类FGQBQItemMatch和PBSMatchTarget，并实现IMatchable和IMatchTarget，然后再由实现IMatchable的类FGQBQItemMatch指定哪此属性（FGQBQItemMatchProperty类）可以用于匹配就行了，如下图：
图3 集成过程
其它-界面
有意思的是，由于这次的界面是动态的，实现过程中使用了装饰模式以重用属性规则编辑器。图就不画了，贴下代码图：
图4 界面代码
最后的界面如下：
图5 最终界面
其它-所有代码图
除了界面以外，整个方案的代码图如下：
图6 所有代码
本文转自BloodyAngel博客园博客，原文链接：http://www.cnblogs.com/zgynhqf/archive/2010/02/05/1664630.html，如需转载请自行联系原作者
