在做任何视觉构建项目时，第一步都是思考如何抽象。如果不抽象，后期构建项目时，API可能会比较乱，难以维护；进行到一半，你甚至会疑惑为什么需要搭建框架，去掉框架会不会更高效；后期发现不自然横向扩展到仪表盘、大屏，形成搭建场景。所以如果你在维护一个可视化构建系统，不管系统上层是BI、大屏、填表、还是脑图，不管是什么，你首先要思考这些背后的底层是什么系统。需要抽象，抽象的意义和价值在哪里。下面结合笔者的经验尝试给出一个思考的角度。精读什么是可视化构建表单构建、中后台应用构建、BI仪表盘构建、大屏构建都属于可视化构建，因为它们都是在画布上拖拽完成的。那么组件配置形式算不算构建呢？专注于单组分分析的视觉探索怎么样？幻灯片呢？比如组件配置表单，如果是基于UI组件树的抽象，就是可视化构建，但是如果是基于表单结构的抽象，就是JsonSchema，但是是不是所有的业务都场景完全将数据映射到UI？不一定，因为UI为了方便用户操作可以增加更多的辅助元素，甚至可以把一个属性拆分成多个UI来填充，所以是基于可视化构建的，即抽象的UI组件树当然可以覆盖所有形成场景，但不一定是最有效的描述方式。如果每个可视化构建场景都定义了一套协议和实现，那么根据构建平台的复杂程度，同时维护两类构建平台的成本要成倍增加，而且不同的维护者也很难沟通。或者一些按照构建思路可以解决的场景，因为缺乏实现经验，没有抽象，甚至是另外一套自定义抽象，回想起来可能很难回归，团队不得不接受现状多套实施繁琐的现状。所以，建议把这些场景当成可视化的构建场景，用一套接口来描述结构和API方法，让看似百花齐放的编辑器有一个统一的语境和实现。视觉构建的分层针对不同类型的视觉构建平台，我们试图找到其分层设计的最大公约数。如果将可视化构建的底层设置为逻辑层，即这一层与UI无关，只关心组件树结构和逻辑功能，那么对于各个平台的分层应该是这样的：表单构建：逻辑层、窗体联动协议层、窗体控制、业务层。中后台应用构建：逻辑层、应用联动协议层、应用控制、业务层。BI仪表盘：逻辑层、筛选联动协议层、可视化控制、业务层。大屏构建：逻辑层、画布编辑控制器层、可视化控制和基本图形控制、业务层。最低的逻辑层应该能够统一所有类型的构建系统，成为开发者的统一上下文。它可以包括以下基本功能：定义组件树结构。定义组件元信息。根据组件树结构递归渲染画布。支持布局、取数据、联动、筛选、验证等一系列扩展能力，业务可按需定制。提供所有业务层所需的能力，如性能优化的组件冻结、状态管理、组件树增删改查API等。逻辑层完成后，开发上层应用程序就会容易很多。只需注册组件，在初始化组件树或组件初始化时添加自定义逻辑，或根据业务需要注册组件元信息，对接系统功能，补充业务特性。比如自定义布局的能力，这样你就可以用简单的话来解释整个系统是如何设计的。逻辑层存在的必要性又回到了问题的根源：对逻辑层进行统一抽象是否多余？要回答这个问题，我们需要知道我们有哪些工具：基本的开发工具html、js、css，而html也提供了一套标准化的xml结构；vue、react等开发框架、基础组件、应用生命周期、事件定义。理论上，基于这些，我们可以直接手写一个可视化构建平台，而且好像不需要抽象。但是当你真正要上手时，肯定会遇到以下一般需要处理的问题：定义组件树结构无论你是构建表单、报表、大屏幕还是脑图画布，首先想到的肯定是canvas的结构怎么描述，不管canvas是横排还是竖排，反正都是一棵树。不能直接移动HTML树。首先，HTML树的完整结构太大，我们需要一个更精简的结构。第二，业务层框架一般先有一组虚拟树，然后再转化为dom树，因果关系不可逆。.而这棵树也可以最大程度的抽象，即定义组件ID、组件名称、属性（Props）、子节点。定义组件树的增删改查功能。有了组件树，需要进行增删改查操作，因为不能基于文档API，而vue、react等上层框架没有提供增删改查的API检查任何标准组件树。这部分Capabilities必然要手动实现。生命周期假设完全依赖React框架提供的组件生命周期，可以完成大部分业务逻辑，但这意味着定义不够细化。比如在组件Mount的实际监控中，我们监控了联动、取数据、设置冻结等效果，虽然也可以实现，但是会遇到是否抽象的问题：如果不是抽象了，业务代码就乱了。难读。如果是抽象的，需要将联动、取数据、冻结等模块进行分类，封装成函数，甚至提供主动调用机制，将UI与逻辑解耦，但是当业务层具体做到这一点时，你会发现，这是在做框架层的抽象工作，所以一开始就把这些生命周期抽象到框架中比较好。逻辑层有两个核心结构。首先是组件树结构，其中包含了每个组件实例的定义；二是组件元信息结构，包含了各个组件的元信息描述，如下图所示。显示：
