Posted on 2007-04-22 23:15
canonical 阅读(1503)
评论(4) 编辑 收藏 所属分类:
Witrix开发平台
在商业产品开发中，如何有效的控制同一产品的多个衍生版本是一个非常重要的问题。客户的需求是多样化，差异化的。这些差异有些很小，可以通过参数配置，资源装载，skin切换等方式加以吸收，而有些则要求对界面布局和程序逻辑等作出较大调整。Witrix开发平台在系统基础架构方面为程序的客户化提供了有力的支持。
1. 多版本控制的关键首先在于系统良好的模块划分。因此Witrix平台的beans,auth-map(权限归约规则)等配置文件格式都支持import/include等基础的分解策略,字符串资源和错误码映射等支持多重定义文件，而对于sql.xml(外部sql语句定义), meta.xml, biz.xml, hbm.xml等配置文件采用分模块动态装载机制。
2. 在Witrix系统中定义了一个特殊的custom目录，规定了一般性的覆盖规则：custom目录作为系统根目录的影子目录，如果custom目录下存在同名文件，则优先装载custom目录下的文件。例如,如果custom目录下存在/_config/my/my.biz.xml文件，同时在根目录下也存在/_config/my/my.biz.xml文件, 则实际装载的是custom目录下的实现。这里的一个关键在于只有meta.xml(元数据)，biz.xml(BizFlow描述文件)，.lib.xml(tpl模板库)等具有一定完整性的文件才支持custom机制，而并不是所有资源都采用custom机制。如果每一个tpl文件，css文件，js文件等都优先从custom目录下装载，则很快就会出现循环引用，相对路径计算将会变得非常混乱，更重要的是我们将无法定义资源删除语义。
3. 元数据文件，BizFlow描述文件，PageFlow描述文件等都支持复杂的extends机制，使得我们在扩展时只需要对于系统差异部分进行描述，而不是大段拷贝代码。
4. tpl模板库和sql-map机制等采用的是追加覆盖策略。例如custom目录下的ui.xml标签库文件并不是直接覆盖系统根目录下的ui.xml文件，而是按照标签名进行细粒度的覆盖。系统编译时会自动检查覆盖标签的所有参数要求和原标签相兼容（例如允许增加参数而不允许减少参数），确保所有引用到原标签的tpl代码仍然有效。实际上整个witrix平台多版本扩展机制的一个设计目标就是确保平台主系统向各个分支产品的单向信息流动。在具体的表现上就是我们随时可以拷贝平台主系统覆盖到分支产品的相应目录，所有扩展实现与主系统实现保持分离状态。当然为了保持设计的弹性，系统中也定义了开关参数用来有选择的跳过一致性检查。
Feedback
canonical：
实际上整个witrix平台多版本扩展机制的一个设计目标就是确保平台主系统向各个分支产品的单向信息流动。在具体的表现上就是我们随时可以拷贝平台主系统覆盖到分支产品的相应目录，所有扩展实现与主系统实现保持分离状态
你说的这个分支版本是指不同的项目吗？
按你的写的，应该是主干版本通过扩展，自定义等手段，以达成项目客户化的版本。如果是这样，那么当主系统的元数据升级后是不能随意覆盖到项目版本的，需要按具体情况具体分析，能直接覆盖的只能是低层的Framework
分支版本可以是不同的产品，不一定是同一产品的不同实施版本。在设计上的要点就是尽量允许主系统升级后可以随意覆盖项目版本，因为项目版本针对主版本的修改是以追加方式进行的，即并不直接修改任何主版本的文件，而是写在独立的文件中，平台负责把custom内容和基础版本内容融合。如果分支版本完全需要采用新的实现，平台提供了完整的替换机制，同时可选择是否校验接口的兼容性。
其实我之前的想法也是和你一样的。认为只要项目实施时以扩展方式，写在独立的文件中，这样就能使核心升级时，不影响到项目，但事实真是这样吗？
后来我觉的，一个业务系统的升级，是需要划分scope的，哪些升级，哪些不升级是需要选择的，因为最终项目可运行版本是 (production core + Custom) 你升级了核心，就可能会影响到这个二元组的结果
比如一个流程，主版本定义 A->B，项目实施时，扩展这个流程A->B-C，主版本若升级后，变成A'->B'，虽然它未覆盖项目实施扩展出来的那部分，但实际的运行过程已经变成A'->B'->C了。
没有人认为核心对分支完全不影响，否则核心升级就没有任何意义。只是升级是可选择的，而且分支可以选择整体覆盖，即扩展后整个流程A->B->C都属于分支