Revit插件兼容2022版本升级策略（3） —方案设计

三、方案设计

a、方案描述

     通过上面两篇文章对背景和问题的分析，我们设计如下解决方案：

     以兼容DIsplayUnityType和UnitForgeId（ForgeTypeId)为例

    1、定义Revit单位类型替换类(UnifyTypeId统一类型ID)

    2、将Revit对象实例中，包含DIsplayUnityType或者UnitForgeId(ForgeTypeId)的

          方法或者属性，进行扩展重写，使用UnifyTypeId替代相关的输入值或者返回值

    3、定义新的抽象静态工具类，将静态工具类中，包含DIsplayUnityType或者           UnitForgeId(ForgeTypeId)的方法进行重写，使用UnifyTypeId替代相关的输入值或者返回值

类型转换图：

方法映射图 

 

 

 

b、设计过程

第一条【1】：以类似2022的实现方式去兼容旧技术，类的表达能力要比枚举强，为了更好的应对未来的变化。适配类型为UnifyTypeId。静态业务分组类UnitForgeId——>AUnitTypeId。A表达抽象

第二条【2】：以扩展方法的形式去扩展，降低使用适配方法的差异化，更容易平滑过渡

例如：

public static FieldType Get<FieldType>(this Entity entity,string fieldName, UnifyTypeId unitTypeId)
        {
#if R20 || R19 || R18
            var current = (DisplayUnitType)GeneralRevitEnvironment.TypeIdMapManager.GetUnitValue(unitTypeId?.TypeId);
            return entity.Get<FieldType>(fieldName, current);
#else
            return entity.Get<FieldType>(fieldName,new ForgeTypeId(unitTypeId.TypeId));
#endif
            return default(FieldType);
        }

第三条【3】：定义统一前缀扩展的静态工具类，例如UnitUtils——>AUnitUtils。方法名称尽量与2022版本保持一致。

 

总结：

现在引申出了两个首要解决的问题：

1、如何找到那些发生变化的过时的枚举，以及这些枚举关联的其他类的方法，属性。

2、如何建立自定义对象UnifyTypeId 与Revit原生对象DisplayUnitType和ForgeTypeId的关系。

我们下一篇去解决这两个问题，并对方案进行初步实现