OneCode核心概念解析——View(视图)

什么是视图？

在前面的章节中介绍过，Page相关的概念，Page是用户交互的入口，具有Url 唯一性。但Page还只是一个抽象的容器，而View则是一个具备了具体业务能力的特殊的Page, 它可以是一个独立的Page也可以作为Page的一个部分。View和Page 一样也是由不同属性的组件来组合完成但不同于普通Page的地方在于，View各组件之间具有密不可分性，各组件相互独立但又相辅相成，共同完成一个面向业务的独立应用。

一，视图组成

（1）设计器展示

视图是面向业务的一个通用单元，包含了数据映射、展现展示、以及动作交互。在设计器中如下图所示：

一个通用的表单包含了，窗体的信息、表格信息、以及可操作工具栏以及基础API调用。

添加图片注释，不超过 140 字（可选）

于视图基础结构对应的则是相应的事件及动作相应，在该示例里主要包含了，1，窗体操作，当用户保存完毕后关闭当前窗体（dialog）视图同步销毁控件（清空缓存），2，工具栏响应当点击工具栏按钮时，对应完成相应的的动作事件。

添加图片注释，不超过 140 字（可选）

（2）DSM视图聚合配置

添加图片注释，不超过 140 字（可选）

2.1 窗体配置

窗体配置是视图的基础配置，主要涉及面板类型，标题，页面缓存（静态JS输出），动态装载（动态渲染实时输出），延展以及图标、缩放目标框架样式等基础性配置。

添加图片注释，不超过 140 字（可选）

2.2 聚合配置

聚合绑定是OneCode-DSM核心的功能之一，在后续的章节中会详细展开说明。在视图中一般绑定聚合类型多数为聚合实体，在聚合实体中允许用户将视图属性以及视图Item（条目）信息完成多级处理。并为每一个原子Item独立完成属性绑定，详细的实体描述会在后续的DSM专题章节中展开描述。

聚合配置除了基础的聚合实体映射之外主要涉及用户空间的选择，以及DSM相关，的聚合跟绑定，源服务以及实体的绑定。在用户空间方面，OneCode 将来自于不同来源的"聚合"做了一个沙箱隔离。比如：从数据库映射而来的库表的Table实体，会进入到通用数据应用环境，而工作表单（流程、表单）这会与之匹配相应的流程工作环境，而系统应用则是由PerCode配置通过，DSM注解注入到OneCodez中的外部API. 而用户自定义以及视图定义则是当前项目工程有项目人员通过工具或项目扩展而来的聚合实体配置。详细的配置及方法会在后续的聚合工厂章节中做详细的描述，这里就不做累述了。

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

2.3 模块（视图）配置

模块配置是根据当前具体视图的具体类型而自动匹配的属性面板，比如当前的主题视图是通用的表单"表格"，这其中主要就包含了，表格的基础布局配置，行、列、合并等基础样式配置，同时对于表格行头等也做了一些独立的配置支持。

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

2.4 动作菜单事件

动作事件是视图聚合中非常重要的一个组成，动作视图主要由可操作的工具栏以及视图相应的事件来组成。工具栏根据展现的位置不同分为窗体菜单（MenuBar）,工具栏（ToolBar）,底部工具栏（BottomBar）、同时根据不同的视图比如TreeView树形视图,GridView列表视图等集合类的视图还有，行按钮（RowMenu）右键菜单（ContextMenuBar）等等。每种工具栏根据其展现的位置不同也很会有其相应的样式哈展现配置

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

视图常用菜单

视图常用菜单是根据不同的视图常用的功能按钮做的一组枚举输出，其目的在于能够在通用的视图操作中能够快速的完成常用配置，类似于传统无代码应用中的"模版"作用，但其相较于传统的模版又具有更高的独立性，具备原子级别的属性支持，同时对于与之关联的动作展现元素也遵循了OneCode的设计规范。支持后端PerCode 前端JS 多端同步输出。并且支持转换换后通过设计器的二次编辑形成混合编译。这是OneCode的一大特点也是去呗与传统模版本质的区别。在后续的DSM原理分析章节中会进一步展开，在此就不再累述。

添加图片注释，不超过 140 字（可选）

DSM自定义业务扩展菜单

在视图菜单中通用的功能菜单能够完成绝大多数交互操作，但在具体的业务中菜单往往需要于具体的业务结合调用相应的业务接口来完成而且这些调用在具体的业务应用中具有很大的通用型在低代码平台中一般称为自定义菜单或者自定义服务，在OneCode在DSM聚合中，将这一类需求进行了具象化设计，允许用户通过指定注解的方式将当前的"接口、服务"声明为一个领域菜单。这样在视图中就可以通过扩展菜单的方式实现复用。

以下代码是一个扩展领域菜单的应用代码：

@Controller
@RequestMapping("/esd/right/")
@MethodChinaName(cname = "权限管理")
@MenuBarMenu(menuType = CustomMenuType.menubar, caption = "权限管理", index = 6, imageClass = "bpmfont bpmgongzuoliu")
//插件显示位置
@Aggregation( rootClass = RightIndex.class,userSpace = UserSpace.SYS)//声明为Domin域
@OrgDomain(type = OrgDomainType.right)//构建当前域环境
public class RightIndex {

    @MethodChinaName(cname = "组件授权")
    @RequestMapping(method = RequestMethod.POST, value = "ComRight")
    @NavTreeViewAnnotation
    @DialogAnnotation(width = "750", height = "600")
    @ModuleAnnotation(dynLoad = true, imageClass = "spafont spa-icon-astext", caption = "组件授权")
    @CustomAnnotation(imageClass = "spafont spa-icon-astext")
    @APIEventAnnotation(customRequestData = {RequestPathEnum.SPA_projectName, RequestPathEnum.SPA_className})
    @ResponseBody
    public TreeListResultModel<List<ComRightTree>> getComRight(String id, String projectName, String currentClassName) {
        return TreePageUtil.getTreeList(Arrays.asList(ComRightFormulaType.values()), ComRightTree.class);
    }

    @MethodChinaName(cname = "模块授权")
    @RequestMapping(method = RequestMethod.POST, value = "ModuleRight")
    @NavTreeViewAnnotation
    @DialogAnnotation(width = "750", height = "600")
    @CustomAnnotation(imageClass = "spafont spa-icon-moveforward")
    @ModuleAnnotation(dynLoad = true, imageClass = "spafont spa-icon-moveforward", caption = "模块授权")
    @APIEventAnnotation(customRequestData = {RequestPathEnum.SPA_projectName, RequestPathEnum.SPA_className})
    @ResponseBody
    public TreeListResultModel<List<ModuleRightTree>> getModuleRight(String id, String projectName, String className) {
        return TreePageUtil.getTreeList(Arrays.asList(ModuleRightFormulaType.values()), ModuleRightTree.class);
    }

    @MethodChinaName(cname = "流程授权")
    @RequestMapping(method = RequestMethod.POST, value = "BpmRight")
    @NavTreeViewAnnotation
    @DialogAnnotation(width = "750", height = "600")
    @CustomAnnotation(imageClass = "bpmfont bpmgongzuoliuzhutiguizeweihuguanli")
    @ModuleAnnotation( dynLoad = true, imageClass = "bpmfont bpmgongzuoliuzhutiguizeweihuguanli", caption = "流程授权")
    @APIEventAnnotation(customRequestData = {RequestPathEnum.SPA_projectName, RequestPathEnum.SPA_className})
    @ResponseBody
    public TreeListResultModel<List<BPMRightTree>> getBpmRight(String id, String projectName, String className) {
        return TreePageUtil.getTreeList(Arrays.asList(BPMRightFormulaType.values()), BPMRightTree.class);
    }

}

2.5 字段子域

字段子域也称为子组件，在示例表单视图中，表单的每一个数据子项对应的就是一个字段子域。在表单中会有其布局信息，数据信息，以及其相应的右键菜单，相应事件等。同时根据每个子项属性不同还会提供相应的扩展属性配置，如示例中，表单部门需要通过，弹出选择树来选择部门，则会定义为一个符合选择框输入，而扩展的弹出框则会通过扩展配置来完成。表单视图是OneCode核心视图之一，在后续的章节中会展开描述这里就不做累述了。

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

二，OneCode 视图工厂

（1）视图工厂简介

OneCode视图工厂（以下简称ViewFactory），是OneCodeDDD领域驱动设计（DSM）的核心组件，其主要设计目的有两个:

一是针对，领域模型设计器形成的设计模型，根据具体的业务环境进行视图的分解以及领域事件的合并绑定，最终组合输出为可被OneCode设计器兼容的视图文件并作为最终工程输出。

ViewFactory另外一个设计用途是将开发者通过低代码可视化设计器设计的视图页面，通过视图工厂进行逆向转换生成"后端网站地图"进行领域模型的二次绑定或者手工编写后端实现代码。

（2），视图工厂运行原理

在领域工厂中，更多是将贫血性的基础实体对象进行聚合分类整理，形成更利于业务理解与操作的充血模型，并且通过在其接口模型上扩展注解的方式实现其低耦合应用。视图工厂中仍然延续这一风格设计将普通单一的组件通过，后端JAVA代码的聚合将常用功能以及辅助组件进行业务封装形成独立的视图组件。 视图工厂同样也是建立在OneCode语法基础上的扩展注解，通过OneCode编译器最终输出为能够被设计器以及前端框架所识别的JSON代码。

添加图片注释，不超过 140 字（可选）

OneCode代码转换实例图

添加图片注释，不超过 140 字（可选）

​

简单列表转换示意

添加图片注释，不超过 140 字（可选）

​

表单渲染

添加图片注释，不超过 140 字（可选）

三，视图工厂设计目的

在视图设计建模中，最容易混淆的一个问题就是，视图设计器与视图工厂的区别是什么？有了视图设计器为什么，还需要视图工厂来建模？视图设计器通过可视化的方式，降低了开发者上手的门槛。但编程本身不单单是一种基础的技能，还需要将业务逻辑，技术技巧进行灵活运用，再分发到实际环境中进一步磨炼，重构，最终形成软件的 "灵魂"业务&技术架构。

这对低代码视图设计方面提出了更高的技术要求：

从业务架构方面能更好的来理解业务语言，诸如：根据业务实体，自动来匹配一张视图。当业务实体发生变更时，自动更新视图。当业务实体的属性发生变化时自动匹配一种更适合用户交互的输入输出方式，如：预警信息显示，红色代表严重、黄色代表警告，绿色代表正常等等。这些在DDD的适用设计采用领域事件与相应的业务域值对象匹配就可以实现通用模型的搭建。

添加图片注释，不超过 140 字（可选）

​

三，视图OneCode统一代码

在完成一个基础视图的建模后，可以调用视图工厂的，GenCode 功能来实现ProCode 生成编译工作。在OneCode中，通常会将一个视图分为三部分编译：

（1）视图实体

视图实体中主要着重于视图实体以及其子对象的实体转换。在实例中我们看到当前表单页面会生成一个AddPersonForm 的视图类。

（2）仓储构建

根据实体的相关属性OneCode 会根据预制规则进行仓储实体的提取转换，并根据转换实体对应完成基础CRUD的基础操作。同时完成相关OneCode 注解转换。

（3）控制接口

控制接口是针对具体的业务服务以及视图信息的在封装，经过封装后可以完成用户访问入口Page设定跨页面交互等基础的业务处理

添加图片注释，不超过 140 字（可选）

四，视图构建三种智能体开发模式

在视图的初始化建模构建方式，OneCode支持三种开发模式：CodeFirst（代码优先），通过JAVA语言体系和Spring注解构建Domain模型；ViewFirst（拖拽优先），通过视图引擎构建交互模型；ModuleFirst（模型优先），前后端模型无缝整合。DSM模型提供了逆向转换和第三方语言支持，能够有效解决低代码平台在复杂逻辑和维护性上的问题，通过预编译提高代码的可维护性和一致性。

（1）智能体（代码优先）模式

OneCode商业版中提供了智能体优先的视图构建模式："Code First" 是 OneCode 平台的核心特色之一，也是实现 "代码优先也能无代码" 范式的关键所在。在 OneCode 中，"Code First" 并不是简单地强调从编写代码开始，而是一种全新的开发思维模式。

对于专业开发者而言，OneCode 的 "Code First" 提供了丰富的代码模板和开发工具，帮助他们快速搭建项目框架。同时，代码大模型会根据开发者输入的代码片段，提供智能提示和代码补全功能，大大提高了代码编写的效率。此外，开发者还可以利用代码大模型对现有代码进行优化和重构，提升代码的质量和性能。

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

（2）视图优先模式（图生代码）

视图有限也称图生代码，顾名思义，就是通过图形化的方式来生成代码。这种方法允许开发者以直观的可视化界面进行设计和建模，然后自动生成相应的代码。它可以大大减少手动编写代码的工作量，降低出错的风险，同时也使得非专业开发人员能够参与到软件开发过程中。而AI 的出现进一步增强了图生代码的能力，例如通过机器学习算法可以自动识别和理解用户的图形化设计意图，更加准确地生成代码。同时，AI 还可以对图形化模型进行标注，为开发者提供更清晰的指导和理解。

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

（3）模型优先（ModuleFrist）

在外观呈现方面，元数据详细定义了组件的布局与定位信息。开发者可以根据实际需求，选择使用绝对像素值来精确固定组件在界面中的位置和大小，或者采用相对比例值实现组件的自适应布局，从而确保应用在不同屏幕尺寸和分辨率的设备上均能呈现出理想的视觉效果。此外，样式属性集涵盖了组件的颜色、字体、背景和边框等方面的详细设置，通过这些设置，开发者能够打造出风格统一且符合企业品牌形象和用户体验要求的应用界面。

模型优先也称元数据设计优先 OneCode 元数据作为应用开发的基础描述信息，全面涵盖了可视化组件的各类属性。每个组件都被赋予特定的标识，如 "chart - 001""form - 002" 等，这一标识确保了组件在整个应用架构中的唯一性和可识别性，便于开发者在开发过程中对其进行精准定位与操作。同时，组件类型与子类型的细致划分，如 "图表类 - 柱状图""表单类 - 输入表单" 等，不仅为开发者提供了丰富的组件选择库，使其能够根据具体业务场景快速匹配到合适的组件，还为平台的智能化管理与优化奠定了基础。

添加图片注释，不超过 140 字（可选）

在外观呈现方面，元数据详细定义了组件的布局与定位信息。开发者可以根据实际需求，选择使用绝对像素值来精确固定组件在界面中的位置和大小，或者采用相对比例值实现组件的自适应布局，从而确保应用在不同屏幕尺寸和分辨率的设备上均能呈现出理想的视觉效果。此外，样式属性集涵盖了组件的颜色、字体、背景和边框等方面的详细设置，通过这些设置，开发者能够打造出风格统一且符合企业品牌形象和用户体验要求的应用界面。

建模工具支持

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）

添加图片注释，不超过 140 字（可选）