1. 科研云首页
  2. 科研百科

低代码设计教程（四）-元模型设计（元模型如何构建）

投稿用户 • • 科研百科 • 阅读 89

我们知道大部分低代码平台都采用了模型驱动的开发模式，即通过可视化建模的方式来实现软件的设计和生成。领域模型创建完成后，有两种技术路线来生成和运行模型应用：

  • 方法一：对生成的模型进行编译并生成所有相关的源代码，使其成为普通的应用系统，该技术称为“代码生成”；
  • 方法二：利用模型解析执行引擎直接解析并运行所生成的模型，该技术称为“模型解析”。

什么是模型驱动开发呢？其实这种架构设计在大型2B的企业项目中是比较常见的：

低代码设计教程（四）-元模型设计（元模型如何构建）

基于元数据建模思路

所谓软件系统设计，核心是对现实的对象进行数字化，如果采用一对一映射建表的“硬建模”，业务对象间的关系分散在各个存储表中，业务对象的新增和变化都会对数据表造成影响，业务对象关系的新增和变化都会对数据表的Schema造成影响。

这里有一张在电信机房的配线架图片，我们分别用“硬建模”和“大类元数据建模”思路来分析两种建模方式的差别。

低代码设计教程（四）-元模型设计（元模型如何构建）

电信机房配线架

“硬建模”方案，我们设计了一个配线架管理的物理模型表（蓝色部分），随着硬件工艺升级，我们的配线架升级为双面配线架，这个时候我们需要增加一个新的模型：操作面（黄色部分）。我们发现这次需求升级，模型改动涉及面很大，增加了三个关系，和操作面相关的模型都需要进行调整，影响了四个模型实体。

低代码设计教程（四）-元模型设计（元模型如何构建）

硬建模方案

这次改动带来的生产影响是什么呢？

  1. 数据库层面新增1个表、改动3个表
  2. 应用层面新增1个对象、改动3个对象，新增3个操作函数
  3. 必须要停止数据库来进行改动操作

采用“硬建模”设计的架构简单可读，项目维护简单，但是一旦需求升级变化，30%的代码都需要进行调整，那么相关的测试、实施投入都相对较大。

“大类元数据建模”方案，我们定义了一个“硬件”大类模型，硬件具备包含、容纳关系能力。针对双面配线架需求，我们的改动仅仅是在元数据中增加了一个“操作面”的定义，如果“操作面”的的属性没超过“硬件”属性范围，我们都不需要增加物理表。如果操作面有特殊属性，我们只需要在物理库增加一张扩展表，而业务关系和核心属性都在主表“硬件”上进行管理，相关的业务代码也无需调整，系统也无需停机。

低代码设计教程（四）-元模型设计（元模型如何构建）

基于大类元数据建模

我们归纳下大类元数据建模思路如下：

  1. 保持大类业务实体和关系实体的稳定，关系全部体现在大类上；
  2. 细类继承大类业务实体和关系实体，以扩展表方式实现灵活扩展；
  3. 通过元数据配置驱动，实现模型快速、在线扩展；

低代码设计教程（四）-元模型设计（元模型如何构建）

大类元数据建模思路

这里我们讲解的大类元数据模型是一种软件架构设计方法，也是低代码软件架构设计方法：既稳定又易用

低代码设计教程（四）-元模型设计（元模型如何构建）

平衡的架构设计

稳定性

越抽象越稳定。E-R是所有MIS数据模型的起源，可以描述世界上任何东西，最稳定。但越抽象，则意味着越多的工作丢需要应用来完成，且不易为程序员和用户理解。

易用性

越贴近现实越容易使用。对现实实体一对一的“硬建模”最容易理解和使用。但建模越“硬”，则意味着停机改动数据模型的可能性越大，越容易对生产造成负面影响。

实用性

实用性取决于应用需要什么抽象度的管理对象。包括：管理对象的粒度——实体（E）和管理对象的功能——关系（R），我们架构设计的过程需要从E-R出发，细分实体和关系概念，直到满足各应用的管理要求为止。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。

赞 (0)
投稿用户
上一篇 2024年1月12日 am10:10
下一篇 2024年1月12日 am10:26

相关推荐