Sailing设计点滴

Sailing 企业架构 架构设计

Initializer和Transformer关系的困扰

问题

概念上来说, Initializer用于实体创建时候的值初始化, 而Transformer用于不同类型实体间转换. 但实际场景貌似没有这么清晰的分界线. 比如拿创建明细单的场景举例:

• 场景一: 明细单允许新建, 完全新建一个明细单, 自己填.
• 场景二: 从外销合同下推出一个明细单.
• 场景三: 新建时选择外销合同, 从外销合同读入数据.
• 补充场景四: 明细单在编辑过程中, 又选择了从商品库中添加一个商品.
• 补充场景五: 明细单在编辑过程中, 又选择了某个外销合同的商品加进来.

对场景一, Initializer应该能满足要求, Initializer填入的值可以是固定, 来自上下文的, 或者来自配置信息的.
对场景二, 典型的Transformer适用范围, Transformer能提供一对一和集合(一对一, 聚合, 分组)的转换规则.

还需要对场景二做进一步剖析. 如果需要对外销合同的商品进行供应商匹配,然后按供应商分组后分单, 那么对源数据分组是一个过程, 根据分组后的数据创建采购合同数据是另一个过程. 这里讨论的主要是后面一个过程, 怎么进行数据分组专题讨论.

对场景三, 很难说到底是Initialization还是transformation.
这里其实已经出现了一个困扰, Transformer在这里完成的工作不也就是初始化实体吗? Initializer和Transformer到底啥关系?

从某个实体的角度来说, Intiailizer从字面量, 配置值, 上下文这几个途径复制给字段, 而Transformer则是以另一个实体作为源来初始化实体的字段;
从集合的角度来说, Initializer根据元数据创建集合元素, 初始化值之后加入集合; 而Transformer也根据元数据规则, 根据源来创建集合元素.

对于场景四和五, 看起来已经不是初始化过程了, 但添加一个商品的动作里面, 又包含有一定的初始化成分.

方案

所以, Initializer和Transformer需要融合! Initializer需要增加Transformer的能力. 也就需要能从源实体中抽取值放入目标中.
落实到最后, 总需要一个字段一个字段的赋值.

• 简单字段直接赋值或从源数据上下文中赋值
• 集合字段需要考虑
  
  • 怎么创建对象. 根据配置创建, 根据源数据上下文创建
  • 怎么为对象的字段赋值. 这个问题等同于简单字段赋值+上下文如何切换

Action的执行模型如何为获取视图状态提供方便

下推动作的按源数据分组后生成多个下游单据, 源数据分组的设计问题

将各组件串联成一个功能

最后的可编程性问题

需要提供前后端的嵌入流程的可编程性端口

Form的设计要点

一个完整的表单应该是由若干组件组成的, 这些组件会有以下要求:

• 一个组件只能绑定一个字段;
  

  此限制可以促使各级开发人员尽量提炼element.

• 一个组件可以有若干的选项用于调节组件的行为或样式(size等); 组件的选项和样式除了可以在初始化时由源数据提供外, 还可能在运行时由外部调整.

  因为组件的选项是有可能在运行时改变的, 那么必须提供一种编程接口来供运行时访问. 要么直接暴露组件对象; 要么将组件选项设计成Reactive风格, 待斟酌?

• 可以用一个或多个组件组合成一个新的组件.

  新组件必须负责声明内部组件的字段绑定关系. 也就是说, 如果一个组件组合了需要字段绑定的内部组件, 那么这个组件本身绑定的必须是一个element, 对应前端的FormGroup.
  新组建也需要负责设置子组件的选项. 当然, 新组建可以暴露自己的一系列选项.

综上所述, 可以看出组件的表示实际上分为了表单绑定关系的表示和实际UI功能的表示两个方面. 对表单绑定关系来说, 可以有以下结论:

• 组件的声明显然也是树状的. 每个节点表示一个组件, 子节点表示组件内部的子组件.
• 如果组件需要绑定字段, 那么是由它的上层来负责声明绑定到什么字段. 也可以认为树结构汇总节点间的连线上记录了绑定字段信息.
• 由于每个组件的[formControlName]都需要放在一个容器中, 因此每个组件在运行时都需要知道所属的FormGroup或FormArray.
• 树的根节点比较特殊, 它没有绑定到任何字段, 但他直接对应了表单对象.

对实际UI功能来说, 可以有以下结论:

• 为了给组件开发者提供尽量大的灵活性和创作空间, 需要允许直接在现有组件的基础上扩展, 而不是基于元数据声明的方式, 因此组件提供全套基于@Input, @Output基础设施的配置方法.
• 基于以上这点, 决定了运行时只能动态创建一层组件, 子组件实际上是随着第一层组件的创建而创建的.
• 从外部也不能访问到组件的子组件状态.
• 由于一个组件其实有可能有两种使用方式: 一种是组件开发者将此组件作为另一个组件的子组件, 这种用法下, 外部组件一般直接通过子组件的@Input, @Output与其通信; 另一种是应用开发者通过元数据声明的方式直接使用zujian, 此时, 框架更倾向于用Reactive的方式来暴露组件接口. 因此, 任何组件都必须同时支持这两种组件通信方式.
• 对于确实需要以声明式的方式为element中的每个字段声明组件的场景, 需要为element提供一个Group组件, 然后将其他子组件放入其中. (这个可以再议).

组合这些组件的表单本身也有一些要求:

• 表单需要容易获取表单数据;
• 表单需要容易获取组件选项;
• 表单需要能附加表单数据计算规则;
• 表单需要能附加组件选项的各种绑定规则;
• 一个表单中的组件可能需要分布于多个panel中;
• 每个panel都有自己的选项, 例如几栏式;
• 一个组件可能出现在多个panel中. (这条也许无法实现);
• 一个实体可能有部分字段通过form来呈现, 部分内容通过table等其他方式来呈现;

综上所述, 表单本身也有若干设计决策:

• 表单或表单服务必须提供一组附加字段计算规则的API;
• 表单或表单服务必须提供一组访问组件或者访问组件选项的API;
• 此外, 因为需要访问组件选项的场景中, 绝大多数是将选项绑定到某个字段上, 因此能提供简单绑定机制
• 由于一个表单的所有内容可能分布在多个panel中, 而表单布局有必须以panel作为单位进行, 因此需要将表单布局逻辑分离出来.

如何避免表单计算公式的循环触发. 例如

单价变化: 总价=单价数量;
数量变化: 总价=单价数量;
总价变化: 数量=总价/单价;

也许可以利用ReactiveForm中的emitModelToView, emitViewToModel选项. 要试验.