上一篇介绍了整合接口平台，架构优化，使用低代码配置模块、实体、模型（https://blog.csdn.net/seawaving/article/details/130642577），今天接着上篇继续写，重点介绍下视图整体的设计。

视图，实际上也就是前端web页面，这部分超级复杂。

先来回顾下整体框架与步骤，如下图所示。

通过实体列表行的“配置”按钮，可以打开实体配置功能，在左侧导航中点击“视图”链接，右侧显示视图列表，该页面包括了视图的新增、修改、删除以及查询、查看功能，如下图 点击新增，创建视图

如上图所示，视图属性不多，但都比较关键，下面展开具体说说。只说概念难以理解，更不清楚为什么要这么做，结合具体实例和场景来介绍设计与实现思路。

根据用途不同，将视图进行了分类，建模产生以下类型的视图

对于对应单一模型的普通实体，如接口平台模块下的应用，对应着列表视图，新增视图、修改视图和查看视图，即囊括了常见的查询、新增、修改、查看页面（删除功能不是一个页面，而仅是一个功能按钮，位于列表页面）。 对于自关联的实体，如组织机构，列表视图如果仅仅是一个表格平铺，难以展现层次关系，直观性很差。这时候就需要树表视图，左边是一个树，右边是一个列表，实际上树表视图是一张由树视图和列表视图组合而成的复合视图。

参照视图是用于供其他实体关联属性时使用的选择页面，如用户需要指定组织机构，具体又可以分为三种：普通参照、树参照和树表参照参照。

普通参照：如在接口平台配置应用的数据权限，需要选择应用，一个数据列表就可以了，对应参照视图。 树参照：用户维护时，选择组织机构，需要一棵树，对应树参照视图。

树表参照：选择用户时，需要左树右表，左边为组织机构树，右边为用户列表，对应树参照视图。树参照实体实际是一张复合视图，由树视图和列表视图组合而来。

此外，还有两种视图，平台做了规划，尚未实现，在这也顺便提一下。 一是主从视图，对于主从关系的实体，如销售订单，使用主从视图，实际跟树表视图类似，也是一种复合视图。 二是自定义视图，用于一些个性化的页面，无法进行标准化配置，通过原生开发实现，指定路径，纳入到整个体系中来。

视图对应的实体模型，视图的数据来自于实体模型，一个实体可能会存在多个模型，因此需要指定下当前视图对应的模型，下面这张图，实际就是一个普通参照视图的实例。

名称，即视图名称，默认同视图类型名称，可根据需要调整。 编码，即视图编码，默认由视图类型编码转换生成。视图类型是通过平台的数据字典来实现的，其命名是常量命名风格（所有字母大写、下划线分隔单词），编码对应着前端vue页面的文件名，使用小驼峰，所以需要转换生成，该转换在前端实现。

此部分平台在生成代码部分，没有做细粒度级别的控制。比如在列表视图，会自动引入编码为add、modify和view视图，将编码改名则需要在代码生成后，人工来二次调整，因此不建议随意修改编码，而是遵循默认约定。

视图加载前、后钩子方法，写js方法体即可，平台会在代码生成环节处理放到前端处理体系中，预处理，主要用于接收参数，设置默认值等，适用于所有视图。

例如，从用户列表视图，在左侧组织机构树中选中财务部节点后，点击新增按钮，打开新增视图，这时候，希望自动填充当前选择的组织机构标识

这里放在初始化后，是因为新增操作首先会调用一个后端实体服务的init操作，创建一个新对象，设置默认值返回，如果放到初始化前，则会将组织机构标识给覆盖掉。

数据验证钩子方法，写js方法体即可，适用于新增视图和编辑视图，用于复合数据验证。单个属性的验证，如不能为空，直接通过form表单的rule规则设置即可。但对于多属性联动，则需要在该方法中进行数据验证。

例如，配置按钮的时候，如果该按钮需要确认，则必须输入确认信息，涉及到confirmFlag和confirmMessage两个属性。

数据保存前、后钩子方法，写js方法体即可，适用于新增视图和编辑视图。平台会在代码生成环节处理放到前端处理体系中，预处理，主要用于处理保存前的数据、触发保存后逻辑等。

视图有五个属性，初始化前、初始化后、数据验证、保存前、保存后，都是平台前端预留的扩展点，用于个性化逻辑和功能的实现，是怎么触发和执行的呢？ 前端使用minx技术，进行混入。

今天先到这，下篇再对不同类型的视图配置进行说明。

平台名称：一二三开发平台 简介： 企业级通用开发平台 设计资料：csdn专栏 开源地址：Gitee 开源协议：MIT 欢迎收藏、点赞、评论，你的支持是我前行的动力。