3.5.6.3 布局的配置

布局是将页面拆分成一个一个的小单元,按照上下中左右进行排列。

前沿

在前端领域中,布局可以分为三大块「Float、Flex、Grid 」,Float可以说的上是上古时期的布局了,如今市面还是很少见的,除了一些古老的网站。

目前,平台主要支持通过配置XML上面的cols和span来进行布局。平台也同样支持自由布局,合理的使用row、col、containers和container四个布局容器相关组件,将可以实现各种类型的布局样式,换句话说,平台实现的自由布局功能是Flex和Grid的结合体。

这里主要是讲解Flex和Grid布局,以及目前新的模板布局实现的思路。

Flex布局

Flex布局采用的是一维布局,那么什么是一维布局呢,所谓的一维布局就是只有一个方向、没有体积、面积,比如一条直线。它适合做局部布局,就像我们原来的顶部菜单、面包屑导航,以及现在的主视图字段配置。

image.png

图3-5-6-19 Flex布局示意

image.png

图3-5-6-20 Flex布局示意

image.png

图3-5-6-21 Flex布局示意

从上图可以看看出,Flex布局只能在X、Y轴进行转换,它无法对上下左右四个方向同时处理,因为它没“面积”的概念。所以它最适合做局部布局。

优点

image.png

图3-5-6-22 Flex兼容性

Flex的兼容性,可以看得出来,目前主流的浏览器都支持该属性。所以Flex兼容性强,如果你想对局部做布局处理,Flex是最好选择。

缺陷

刚刚也提到了,用户想要的布局是千奇百怪的,如果他想要的布局在现有的功能中无法实现怎么办?让用户放弃?还是说服他使用现在的布局。

Grid布局

Grid布局系统采用的是二维布局,二维布局有四个方向:上、下、左、右,它只有面积没有体积,比如一张纸、网格。

Grid布局
<div id="grid-container-one">
  <div class="one-1">Grid Item 1</div>
  <div>Grid Item 2</div>
  <div>Grid Item 3</div>
  <div>Grid Item 4</div>
  <div>Grid Item 5</div>
  <div class="one-6">Grid Item 6</div>
</div>

<div id="grid-container-two">
  <div class="tow-1">Grid Item 1</div>
  <div class="tow-2">Grid Item 2</div>
  <div>Grid Item 3</div>
  <div>Grid Item 4</div>
  <div>Grid Item 5</div>
  <div>Grid Item 6</div>
</div>

<div id="grid-container-three">
  <div>Grid Item 1</div>
  <div>Grid Item 2</div>
  <div class="grid">Grid Item 3</div>
  <div class="grid-column">Grid Item 4</div>
  <div>Grid Item 5</div>
  <div>Grid Item 6</div>
  <div>Grid Item 7</div>
  <div class="grid-column">Grid Item 8</div>
</div>
HTML CSSResult Skip Results Iframe
EDIT ON
* {
  box-sizing: border-box;
  padding: 0;
  margin: 0;
  line-height: 1.5;
  font-weight: bold;
  text-align: center;
}

#grid-container-one{
  background-color: black;
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: repeat(2, 50px);
  gap: 10px;
  border: solid black 2px;
  margin-bottom: 20px;
  color: salmon;
}

#grid-container-one div {
  border: solid white 2px;
  padding: 10px;

}

#grid-container-one .one-1 {
    grid-area: span 1/span 3;
    text-aligin: center
}

#grid-container-one .one-6 {
    grid-column: 3 /4;
}

#grid-container-two{
  background-color: CADETBLUE;
  display: grid;
  grid-template-columns: 15% repeat(2, 1fr);
  grid-template-rows: 100px;
  text-shadow: 1px 1px 3px black;
  margin-bottom: 20px;
  color: salmon;
}

.tow-1 {
  grid-area: span 3 / span 1
}
.tow-2 {
  grid-area: span 1 / span 2
}

#grid-container-two div{
  border: solid white 2px;
  padding: 10px;
}

#grid-container-three{
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-template-rows: 25%;
  grid-auto-rows: 200px; 
  grid-auto-columns: 100px;
  gap: 2px;
  color: black;
  text-decoration: underline;
  margin-bottom: 2%;
}

#grid-container-three div{
  background-color: salmon;
  border: solid black 5px;
  padding: 10px;
}

.grid-column{
  grid-column: 5 / 7;
}

.grid{
  grid-row: 1 /1;
  grid-column: 4 / 5;
}

.grid-container-inline{
  display: inline-grid;
  grid-template-columns: repeat(2, 200px);
  grid-template-rows: 100px 100px;
  gap: 2px;
  margin-bottom: 20px;
}

.grid-container-inline div{
  padding: 35px;
  border: solid black 2px;
  background-color: PINK;
}

Resources1× 0.5× 0.25×Rerun

3.5.6.3 布局的配置

图3-5-6-23 Grid布局示意

从上面的代码可以看出,Grid天生的支持整体布局,它甚至可以移行换位,它的强大之处可以颠覆你对布局的认知。

缺陷

虽然Grid很强大,但是它有一个致命的缺陷,那就是兼容性。

image.png

图3-5-6-24 Grid兼容性

从上图可以看出,IE10以下、Chrome56以下、Firefox51以下等等都不支持该属性。

平台布局

名词解释

-布局容器相关组件:rowcolcontainerscontainer这四个组件的统称。

-基础布局属性:包括colscolSpanspanoffset

概述

一般的,我们对大多数组件提供了基本的布局属性配置,包括:

  • cols:将内容区中的每行拆分的列数;当前元素未配置该属性时,将取离当前元素最近父元素属性。默认:1
  • colSpan:当前元素相对于父元素在每行中所占列比例;优先于span。默认:FULL
    • FULL:1
    • HALF:1/2
    • THIRD:1/3
    • TWO_THIRDS:2/3
    • QUARTER:1/4
    • THREE_QUARTERS:3/4
  • span:当前元素相对于父元素在每行中所占列数。默认:cols
  • offset:当前元素相对于原所在列的偏移列数。

我们规定了默认栅格数为24,基础布局属性均是相对于默认栅格数而言的。

在使用基础布局属性时,请尽可能保证公式 (24 / cols) * span 以及以下列举的公式,其计算结果为整数,否则可能出现不符合预期的结果。

在使用colSpan时,span的计算公式为:span = cols * colSpan

在使用offset时,offset的计算公式为:offset = (24 / cols) * offset

平台内置组件

下面列举了平台内置组件在FormDetail视图中使用时所支持的布局相关属性,包括可能影响部分区域显隐的相关属性。

表头说明:

  • tag:xml配置标签
  • widget:组件名称;xml属性;多个值属于别称。如:widget="form"
  • 配置项:xml属性名称。
  • 可选值:声明支持的配置项属性类型,不可识别或不可解析时将采用默认值。
  • 作用:对配置项的简单描述,部分布局属性在上方进行了描述,不再赘述。
tag widget 配置项 可选值 默认值 作用
view cols number 1
element form cols number 1
colSpan enum FULL
span number cols
offset number
detail cols number 1
colSpan enum FULL
span number cols
offset number
DateTimeRangePicker colSpan enum FULL
span number cols
offset number
DateRangePicker colSpan enum FULL
span number cols
offset number
TimeRangePicker colSpan enum FULL
span number cols
offset number
colSpan enum FULL
YearRangePicker span number cols
offset number
field 任意 colSpan enum FULL
span number cols
offset number
pack fieldset/group cols number 1
colSpan enum FULL
span number cols
offset number
title string 分组 标题;空字符串或不填,则隐藏标题区;
tabs cols number 1
colSpan enum FULL
span number cols
offset number
tab cols number 1
title string 选项页 标题;必填;空字符串或不填则显示默认值;
row cols number 1
align top/middle/bottom 垂直对齐方式
justify start/end/center/space-around/space-between 水平对齐方式
gutter number,number?示例:24 = 24,2412,12 24,24 水平/垂直间距
wrap boolean true 是否允许换行
col cols number 1
colSpan enum FULL
span number cols
offset number 偏移单元格数
mode/widthType manual/full manual 列模式;手动/自动填充;使用自动填充时,将忽略span、offset属性;
containers cols number 1
align top/middle/bottom 垂直对齐方式
justify start/end/center/space-around/space-between 水平对齐方式
gutter number,number?示例:24 = 24,2412,12 0,24 水平/垂直间距
wrap boolean true 是否允许换行
container cols number 1
colSpan enum FULL
span number cols
offset number 偏移单元格数
align top/middle/bottom 垂直对齐方式
justify start/end/center/space-around/space-between 水平对齐方式
gutter number,number?示例:24 = 24,2412,12 0,24 水平/垂直间距
wrap boolean true 是否允许换行
mode/widthType manual/full full 列模式;手动/自动填充;使用自动填充时,将忽略span、offset属性;

表3-5-6-11 平台内置组件

基础布局

    基础布局提供了在不使用任何布局容器相关组件的情况下,仅使用cols、span、offset这三个属性控制行列的布局能力。

    其本质上是flex布局的扩展,但依旧无法脱离flex布局本身的限制,即元素始终是自上而下、自左向右紧凑的。

    下面将使用fieldset和tabs/tab组件来介绍各个属性在实际场景中的使用。

示例1:默认撑满一行

<pack widget="fieldset" title="示例1">
    <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
    <field data="name" widget="Input" label="名称" placeholder="请输入" required="true" />
</pack>

图3-5-6-25 示例1:默认撑满一行

结果展示

image.png

图3-5-6-26 示例效果

示例2:一行两列:cols=2; colSpan=HALF/span=1

<pack widget="fieldset" title="示例2" cols="2">
    <field data="code" widget="Input" colSpan="HALF" label="编码" placeholder="请输入" required="true" />
    <field data="name" widget="Input" colSpan="HALF" label="名称" placeholder="请输入" required="true" />
</pack>
------------------------------ 或 ------------------------------
<pack widget="fieldset" title="示例2" cols="2">
    <field data="code" widget="Input" span="1" label="编码" placeholder="请输入" required="true" />
    <field data="name" widget="Input" span="1" label="名称" placeholder="请输入" required="true" />
</pack>

图3-5-6-27 示例2代码

结果展示

image.png

图3-5-6-28 示例效果

示例3:使用offset实现中间空一个字段空间的布局

<pack widget="fieldset" title="示例3" cols="3">
    <field data="code" widget="Input" span="1" label="编码" placeholder="请输入" required="true" />
    <field data="name" widget="Input" span="1" offset="1" label="名称" placeholder="请输入" required="true" />
</pack>

PS:offset的作用有限,offset最优实践的前提是在同一行中进行偏移,要实现特殊布局功能,请使用自由布局相关布局能力。

图3-5-6-29 使用offset实现中间空一个字段空间的布局

结果展示

image.png

图3-5-6-30 示例效果

示例4:属性cols就近取值

<!-- 所有tab将使用cols="2"属性 -->
<pack widget="tabs" cols="2">
    <pack widget="tab" title="示例4-1">
        <field data="code" widget="Input" span="1" label="编码" placeholder="请输入" required="true" />
    </pack>
    <pack widget="tab" title="示例4-2">
        <field data="name" widget="Input" span="1" label="名称" placeholder="请输入" required="true" />
    </pack>
</pack>

图3-5-6-31 示例4:属性cols就近取值

结果展示

image.png

图3-5-6-32 示例效果

image.png

图3-5-6-33 示例效果

<!-- 所有tab将使用cols="2"属性 -->
<pack widget="tabs" cols="2">
    <!-- 特指该tab使用cols="1"属性,其他tab继续使用tabs配置的cols="2"属性 -->
    <pack widget="tab" title="示例4-1" cols="1">
        <field data="code" widget="Input" span="1" label="编码" placeholder="请输入" required="true" />
    </pack>
    <pack widget="tab" title="示例4-2">
        <field data="name" widget="Input" span="1" label="名称" placeholder="请输入" required="true" />
    </pack>
</pack>

图3-5-6-34 实例4:tab属性生效

结果展示

image.png

图3-5-6-35 示例效果

image.png

图3-5-6-36 示例效果

自由布局

自由布局提供了无法通过基础布局能力实现的其他布局能力,总的来说,自由布局是对grid布局和flex布局的结合,它既拥有grid布局对页面进行单元格拆/合的能力,在每个单元格中,使用flex布局进行紧凑排列。

下面将使用fieldset组件介绍各个属性在实际场景中的使用。

组件组合

row/col:两个组件共同形成行和列,在一行中拆分成24个栅格,每个列的跨度不超过24。当一行中,所有列的跨度和超过24时,将会自动换行。

containers/row/container:三个组件共同形成一个二维网格,以此实现grid布局的基本能力。每个单元格(container)中使用flex布局。

PS:以下示例为了体现布局效果,可能会出现重复字段定义,业务上在使用时需要避免这种定义。

示例1:仅使用1/2左侧空间

小贴士:在使用row和col组合时,如果在一个col中有且仅有一个子元素,则col可以缺省。col相关属性可以配置在该子元素上。

<pack widget="fieldset" title="示例1">
    <pack widget="row" cols="2">
        <!-- 此处显式定义col组件,field标签上的基础布局属性将失效 -->
        <pack widget="col" span="1">
            <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
        </pack>
    </pack>
    <pack widget="row" cols="2">
        <pack widget="col" span="1">
            <field data="name" widget="Input" label="名称" placeholder="请输入" required="true" />
        </pack>
    </pack>
</pack>
------------------------------ 或 ------------------------------
<pack widget="fieldset" title="示例1">
    <pack widget="row" cols="2">
        <!-- 此处缺省col组件,field标签上的基础布局属性可生效 -->
        <field data="code" widget="Input" span="1" label="编码" placeholder="请输入" required="true" />
    </pack>
    <pack widget="row" cols="2">
        <field data="name" widget="Input" span="1" label="名称" placeholder="请输入" required="true" />
    </pack>
</pack>

图3-5-6-37 仅使用1/2左侧空间

结果展示

image.png

图3-5-6-38 示例效果

示例2:使用布局容器实现中间空一个字段空间的布局

<pack widget="fieldset" title="示例2">
    <pack widget="containers">
        <pack widget="row">
            <pack widget="container">
                <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
            </pack>
            <pack widget="container"></pack>
            <pack widget="container">
                <field data="name" widget="Input" label="名称" placeholder="请输入" required="true" />
            </pack>
        </pack>
    </pack>
</pack>

图3-5-6-39 使用布局容器实现中间空一个字段空间的布局

结果展示

image.png

图3-5-6-40 示例效果

示例3:一行5列(基础布局属性公式无法计算出整数的情况)

<pack widget="fieldset" title="示例3">
    <pack widget="containers">
        <pack widget="row">
            <pack widget="container">
                <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
            </pack>
            <pack widget="container">
                <field data="name" widget="Input" label="名称" placeholder="请输入" required="true" />
            </pack>
            <pack widget="container">
              <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
            </pack>
            <pack widget="container">
              <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
            </pack>
            <pack widget="container">
              <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
            </pack>
        </pack>
    </pack>
</pack>

图3-5-6-41 一行5列(基础布局属性公式无法计算出整数的情况)

结果展示

image.png

图3-5-6-42 示例效果

示例4:共2行,其中1行未3列,另1行为2列

该示例可以使用任何一种组件组合都可以实现,结果一致。

<!-- 使用containers/row/container -->
<pack widget="fieldset" title="示例4">
    <pack widget="containers">
        <pack widget="row">
            <pack widget="container">
                <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
            </pack>
            <pack widget="container">
                <field data="name" widget="Input" label="名称" placeholder="请输入" required="true" />
            </pack>
            <pack widget="container">
                <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
            </pack>
        </pack>
        <pack widget="row">
            <pack widget="container">
                <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
            </pack>
            <pack widget="container">
                <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
            </pack>
        </pack>
    </pack>
</pack>
------------------------------ 或 ------------------------------
<!-- 使用row/col,其中col缺省 -->
<pack widget="fieldset" title="示例4">
    <pack widget="row" cols="3">
        <field data="code" widget="Input" span="1" label="编码" placeholder="请输入" required="true" />
        <field data="name" widget="Input" span="1" label="名称" placeholder="请输入" required="true" />
        <field data="code" widget="Input" span="1" label="编码" placeholder="请输入" required="true" />
    </pack>
    <pack widget="row" cols="2">
        <field data="code" widget="Input" span="1" label="编码" placeholder="请输入" required="true" />
        <field data="code" widget="Input" span="1" label="编码" placeholder="请输入" required="true" />
    </pack>
</pack>

图3-5-6-43 示例为共2行,其中1行未3列,另1行为2列

结果展示

image.png

图3-5-6-44 示例效果

示例5:布局容器的垂直居中

左侧容器高度被子元素撑开,右侧容器在垂直方向居中

<pack widget="fieldset" title="示例5">
    <pack widget="containers">
        <pack widget="row">
            <pack widget="container">
                <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
                <field data="name" widget="Input" label="名称" placeholder="请输入" required="true" />
            </pack>
            <pack widget="container" align="middle">
                <field data="code" widget="Input" label="编码" placeholder="请输入" required="true" />
            </pack>
        </pack>
    </pack>
</pack>

图3-5-6-45 设置布局容器的垂直居中

结果展示

image.png

图3-5-6-46 示例效果

举例

这里拿PetTalent举例,仿造教程上面效果,除了例子中的效果,自己可以做更多的尝试

Step1 修改PetTalent的form视图如下

给creater字段增加一个属性配置 offset="1"

<field data="creater" widget="SSConstructSelect" offset="1" submitFields="creater,name" responseFields="name"/>

图3-5-6-47 给creater字段增加一个属性配置 offset="1"

Step2 重启看效果

image.png

图3-5-6-48 示例效果

Step3 修改PetTalent的form视图如下

给【基础信息】增加一个属性cols="4",给name字段增加一个属性span="2",给creater和nick字段增加一个属性span="1":

<pack widget="group" title="基础信息" cols="4">
    <field invisible="true" data="id" label="ID" readonly="true"/>
    <field data="name" label="达人" required ="true" span="2"/>
    <field data="nick" compute="activeRecord.name" readonly = "true" span="1"/>
    <field data="creater" widget="SSConstructSelect"  submitFields="creater,name" responseFields="name" span="1"/>
    <field data="dataStatus" label="数据状态" >
        <options>
            <!-- option name="DRAFT" displayName="草稿" value="DRAFT" state="ACTIVE"/ -->
            <option name="NOT_ENABLED" displayName="未启用" value="NOT_ENABLED" state="ACTIVE"/>
            <option name="ENABLED" displayName="已启用" value="ENABLED" state="ACTIVE"/>
            <option name="DISABLED" displayName="已禁用" value="DISABLED" state="ACTIVE"/>
        </options>
    </field>
    <field invisible="true" data="createDate" label="创建时间" readonly="true"/>
    <field invisible="true" data="writeDate" label="更新时间" readonly="true"/>
    <field data="createUid" label="创建人id"/>
    <field data="writeUid" label="更新人id"/>
</pack>

图3-5-6-49 修改PetTalent的form视图

Step4 重启看效果

image.png

图3-5-6-50 示例效果

Oinone社区 作者:史, 昂原创文章,如若转载,请注明出处:https://doc.oinone.top/oio4/9262.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

(0)
史, 昂的头像史, 昂数式管理员
上一篇 2024年5月23日 am9:16
下一篇 2024年5月23日 am9:18

相关推荐

  • 6.1 文件与导入导出(改)

    导入导出在一定程度上是企业级软件和效率工具(office工具)的桥梁 文件的上传下载以及业务数据的导入导出是企业级软件一个比较常规的需求,甚至是巨量的需求。业务有管理需要一般都伴随有导入导出需求,导入导出在一定程度上是企业级软件和效率工具(office工具)的桥梁。oinone的文件模块就提供了通用的导入导出实现方案,以简单、一致、可扩展为目标,简单是快速入门,一致是用户操作感知一致、可扩展是满足用户最大化的自定义需求。 下图为文件导入导出的实现示意图,大家可以做一个整体了解 图6-1-1 文件导入导出实现示意图 一、基础能力 准备工作 pamirs-demo-api的pom文件中引入pamirs-file2-api包依赖 <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-file2-api</artifactId> </dependency> 图6-1-2 引入pamirs-file2-api包依赖 DemoModule增加对FileModule的依赖 @Module(dependencies = {FileModule.MODULE_MODULE}) 图6-1-3 DemoModule增加对FileModule的依赖 pamirs-demo-boot的pom文件中引入pamirs-file2-core包依赖 <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-file2-core</artifactId> </dependency> 图6-1-4 启动工程引入pamirs-file2-core包依赖 pamirs-demo-boot的application-dev.yml文件中增加配置pamirs.boot.modules增加file,即在启动模块中增加file模块 pamirs: boot: modules: – file 图6-1-5 pamirs-demo-boot的application-dev.yml文件中增加配置 pamirs-demo-boot的application-dev.yml文件中增加oss的配置。更多有关文件相关配置详见4.1.1【模块之yml文件结构详解】一文 cdn: oss: name: 阿里云 type: OSS bucket: demo uploadUrl: #换成自己的oss上传服务地址 downUrl: #换成自己的oss下载服务地址 accessKeyId: #阿里云oss的accessKeyId accessKeySecret: #阿里云oss的accessKeySecret mairDir: upload/demo #换成自己的目录 validTime: 360000 timeout: 60000 active: true referer: www.shushi.pro 图6-1-6 application-dev.yml文件中增加oss的配置 其他文件系统支持 a. 文件系统类型 类型 服务 OSS 阿里云 UPYUN 又拍云 MINIO Minio HUAWEI_OBS 华为云 LOCAL 本地文件存储 表6-1-1 支持的文件系统类型 b. OSS配置示例 ⅰ. 华为云OBS cdn: oss: name: 华为云 type: HUAWEI_OBS bucket: pamirs #(根据实际情况修改) uploadUrl: obs.cn-east-2.myhuaweicloud.com downloadUrl: obs.cn-east-2.myhuaweicloud.com accessKeyId: 你的accessKeyId accessKeySecret: 你的accessKeySecret # 根据实际情况修改 mainDir: upload/ validTime: 3600000 timeout: 600000 active: true allowedOrigin: http://192.168.95.31:8888,https://xxxx.xxxxx.com referer: 图6-1-7 OBS的配置说明 ⅱ. MINIO cdn: oss: name: minio type: MINIO bucket: pamirs #(根据实际情况修改) uploadUrl: http://192.168.243.6:32190 #(根据实际情况修改) downloadUrl: http://192.168.243.6:9000 #(根据实际情况修改) accessKeyId: 你的accessKeyId accessKeySecret: 你的accessKeySecret # 根据实际情况修改 mainDir: upload/ validTime: 3600000 timeout: 600000 active: true referer: localFolderUrl: 图6-1-8 MINIO的配置说明 ⅲ. 又拍云 cdn: oss: name: 又拍云 type: UPYUN bucket: pamirs #(根据实际情况修改) uploadUrl: v0.api.upyun.com downloadUrl: v0.api.upyun.com accessKeyId: 你的accessKeyId accessKeySecret: 你的accessKeySecret # 根据实际情况修改 mainDir: upload/ validTime: 3600000 timeout: 600000…

    2024年5月23日
    1.2K00
  • 7.2 实战训练(积分发放)

    前言 当我们碰到一个全新的场景,除了写代码以外也可以通过设计器来完成,大致步骤如下: 分析业务场景,规划对应的模型并通过模型设计器进行配置 通过界面设计器,设计出必要管理页面 通过流程设计器,设计对应业务流程 通过数据可视化,设计相应的数据看板 场景说明 本节通过例子完成一个积分成本分摊的业务场景 积分支出:谁受益谁支出原则+导购手动确认原则,通过门店应用的积分规则,来实现自动化+手动积分形式实现 案例背景 某家具企业经营多种家具类型,不同系列不同品类分事业部经营。 注: 独立门店:只能售卖本事业部下的商品; 融合门店:可以售卖多事业部下的商品; 需求:需要建立一套积分规则,遵循谁受益谁支出原则+导购手动确认原则;通过门店应用的积分规则,来实现自动化+手动积分。 场景一 导购a邀请老客户c通过裂变分享新客户x在独立门店1下单。系统根据独立门店1的积分规则,自动发放积分给老客户c和新客户x,积分由国一事业部承担。 场景二 融合门店1导购b邀请老客户d裂变分享新客户y在融合门店下单。该订单可能涉及多个事业部,由导购b手动选择最大量值的积分规则进行发放 场景三 独立门店1的导购a邀请老客户c裂变分享新客户z在独立门店2下单。系统根据独立门店2的积分规则,来计算积分值,自动发放老客户c和新客户z的积分,积分由国二事业部 实战训练 Step1 分析业务场景规划对应模型 本场景下涉及基础对象模型包括:事业部、门店、导购、会员等 事业部:它是积分成本的载体 门店:类型分为独立门店和融合门店,独立门店必须隶属于一个事业部,同时配置默认积分发放规则,融合门店可能属于多个事业部当发生积分发放时,需要店员手工选择成本事业部和积分发放规则 导购员:导购员必须隶属于一个门店等 会员:消费者需要记录它隶属导购员,以及是由哪个会员推荐过来的等 涉及业务对象模型包括:积分发放规则,积分发放记录,邀请下单记录 积分发放规则:会员积分发放规则,对应邀请老客的积分发放规则等 积分发放记录:本次发放积分、本次发放积分规则、发放对象(会员)、成本事业部、关联门店、关联导购、关联老客(可空)、关联下单记录编码等 邀请下单记录:导购、下单会员、下单门店、商品信息、下单金额等 对应模型如下: 模型 设计器呈现 自定义字段列表 关系字段说明 说明 事业部 事业部负责人(文本) 门店列表(o2m) 与门店建立o2m绑定关系,绑定时选择双向绑定,双向绑定意思是在事业部这边建立o2m到门店的关系字段,在门店那边建立m2o的关系字段 关系字段需要在有对方模型的情况下再建,比如事业部中的门店列表则是再后面追加新增的 门店 导购列表(o2m) 事业部(m2o) 默认积分发规则(m2o) 门店类型(枚举) 分别与事业部、导购、积分发放规则建立m2o、o2m、m2o关系 门店类型:需要先建对应的数据字典 导购 绑定用户(m2o) 门店(m2o) 是否离职(布尔型) 与门店建立m2o关系 1. 绑定用户,用于后续业务流程设计中的填写规则 2. 打马赛克的忽略,其他场景测试用 会员 会员累计积分(浮点数) 推荐客户(m2o) 所属于导购员(m2o) 是否为新客(布尔型) 与导购、会员建立m2o关系 1. 会员m2o的字段是自关联用于存储推荐会员 2. 打马赛克的忽略,其他场景测试用 积分发放规则 推荐客户发放比例(浮点数) 发放倍数(整数) 积分发放记录 最终发放积分(浮点数) 关联积分规则(m2o) 事件编码(文本) 推荐导购员(m2o) 推荐会员(m2o) 关系门店(m2o) 成本事业部(m2o) 会员(m2o) 成本事业部名称(文本) 会员名称(文本) 与积分发放规则、导购员、会员、门店、事业部建立m2o关系 1. 会员有两个m2o,分别用户记录发放会员和发放会员的推荐会员也就是老客 2. 事件编码用户维护触发本次积分发放记录产生的源头单据编码如:邀请下单记录的编码 邀请下单记录 成本事业部(m2o) 选择积分发放规则(m2o) 下单门店(m2o) 购买商品(文本) 下单金额(整数) 会员(m2o) 导购(m2o) 与成本事业部、积分发放规则、下单门店、会员、导购等建立m2o的关系 1. 会员、下单门店、导购属于必要信息 2. 成本事业部、积分发放规则是业务流程中自动计算回填的数据 Step3 利用界面设计器,设计出必要的管理页面 以事业部为例,构建管理页面。其他模型依次按例子建立管理页面 进入界面设计器,应用选择全员营销,模型选择事业部,点击添加页面下的直接创建 设置页面标题、模型(自动带上可切换)、业务类型(运营管理后续会扩展其他类型)、视图类型(表单)后点击确认按钮进入事业部表单设计页面 进入页面设计器,对事业部表单页面进行设计(更多细节介绍,请参考界面设计产品使用手册) a. 左侧为物料区:分为组件、模型。 ⅰ. 【组件】选项卡下为通用物料区,我们可以为页面增加对应布局、字段(如同在模型设计器增加字段)、动作、数据、多媒体等等 ⅱ. 【模型】选项卡下为页面对应模型的自定义字段、系统字段、以及模型已有动作 b. 中间是设计区域 c. 右侧为属性面板,在设计区域选择中组件会显示对应组件的可配置参数 在左侧【组件】选项卡下,拖入布局组件【分组】,并设置组件【标题属性】为基础信息 在左侧【组件】选项卡下,再次拖入布局组件【分组】,并设置组件【标题属性】为门店列表 在左侧【模型】选项卡下,分别把自定义字段中的【事业部负责人】和系统字段中的【名称】拖入【基础信息】分组,把自定义字段中的【门店列表】字段拖入门店列表分组 在设计区域切换【门店列表】展示组件为【表格】 此时【门店列表】展示形式变成了表格形式,选中【门店列表】组件,会发现左侧【模型】选项卡下的当前模型切换成了【门店】,同时我们在右属性面板区置空其【标题属性】 设计区选中【门店列表】的表格组件,分别把自定义字段中的【默认积分发规则】、【门店类型】、【导购列表】和系统字段中的【名称】拖入【门店列表】表格组件的表格字段设计区 设计区选中【门店列表】的表格组件的【创建】按钮,点击【打开弹窗】设计关系字段【门店】的新增页面 11.分别把自定义字段中的【默认积分发规则】、【门店类型】和系统字段中的【名称】拖入门店的新增页面设计区 选中弹出框中【取消】取消按钮,设置其【按钮样式】属性为【次要按钮】 关闭弹出框,回到主设计区 设计区选中【门店列表】的表格组件的【删除】按钮,设置其【按钮样式】属性为【次要按钮】,【二次确认】属性打开 设计区选中【门店列表】的表格组件中操作列的【编辑】按钮,点击【打开弹窗】设计关系字段【门店】的编辑页面, a. 分别把自定义字段中的【默认积分发规则】、【门店类型】和系统字段中的【名称】拖入门店的新增页面设计区。 b. 选中弹出框中【取消】取消按钮,设置其【按钮样式】属性为【次要按钮】 c. 把门店类型展示组件切换为【单选框】 d. 关闭弹出框 设计区选择非【门店列表】组件如基础信息,模型切换为主模型【事业部】,在左侧【模型】选项卡下,把动作分类下的提交类型【创建】动作拖入中间设计区的动作区 选择中展示名为【确定】的创建动作按钮,在右侧属性面板中设置:是否隐藏属性为【条件隐藏】,隐藏条件为【id非空】 在左侧【模型】选项卡下,把动作分类下的提交类型【更新】动作拖入中间设计区的动作区 选择中展示名为【确定】的更新动作按钮,在右侧属性面板中设置:是否隐藏属性为【条件隐藏】,隐藏条件为【id为空】。之所以同时拖入【创建】和【更新】动作并都命名为确认,是期望这个页面同时可以做为新增页面也可以做为编辑页面,只不过要通过条件隐藏来设置按钮的出现规则 在左侧【组件】选项卡下,把动作分类下的【客户端动作】拖入中间设计区的动作区 选择设计区【客户端动作】,在右侧属性面板中设置:动作名称为【返回】,客户端行为为【返回上一个页面】并点击保存 选择设计区【返回】动作,在右侧属性面板中设置:按钮样式为【返回】,【二次确认】属性打开并设置提示文字为【返回页面操作将不被保存】,可以点击预览二次确认看效果 点击【发布】按钮,页面成功发布,每发布一次会有一个例子版本,可以通过历史版本进行恢复 点击右上角历史版本图标,进入历史版本查看页面 在历史版本页面可以选择对应历史版本记录,并通过【恢复此版本】来完成页面的历史版本切换 接下来我们为事业部模型创建表格管理页面,入口同编辑页面。设置页面标题、模型(自动带上可切换)、业务类型(运营管理后续会扩展其他类型)、视图类型(表格)后点击确认按钮进入事业部表格设计页面 进入页面设计器,对事业部表格页面进行设计(更多细节介绍,请参考界面设计产品使用手册) 在左侧【模型】选项卡下,分别把自定义字段中的【事业部负责人】和系统字段中的【名称】拖入表格组件的表格字段设计区 在左侧【组件】选项卡下,把动作分类下的【跳转动作】拖入中间设计区的动作区,并在右侧属性面板中设置动作名称为【新增】,数据控制类型为【不进行数据处理】,打开方式为【当前窗口打开】,动作跳转页面为【事业部编辑】页面,并点击保存 在左侧【组件】选项卡下,把动作分类下的【跳转动作】拖入中间设计区的行内动作区,并在右侧属性面板中设置动作名称为【编辑】,数据控制类型为【处理单条数据】,打开方式为【当前窗口打开】,动作跳转页面为【事业部编辑】页面,并点击保存 在左侧【模型】选项卡下,把动作分类下的【删除】拖入中间设计区的动作区,并在右侧属性面板中设置动作名称为【删除】,按钮样式为【次要按钮】,【二次确认】属性打开 点击右上角【显示母版】进入页面最终展示形式,点击添加菜单项,并在输入框中输入【事业部管理】 点击菜单右侧设置图标,选择【绑定已有页面】,进行菜单与页面的绑定操作 在绑定页面中,模型选择【事业部】,视图选择【事业部管理】,点击确认按钮提交 拖动【事业部管理】菜单到【积分管理】父菜单下 最后别忘了点击右上角【发布】按钮对【事业部管理】表格页面进行发布,回到界面设计器首页查看刚刚建好的两个页面 以事业部为例分别对门店、导购、会员、积分发放规则、积分发放记录、邀请下单记录等模型进行页面设计,这里不再累赘,请按照自身学习需要,尝试进行界面设计 Step4 通过流程设计器,设计对应业务流程 我们先来整理下核心流程即:邀请下单流程 Step4.1 创建导购邀请下单记录触发流程 进入流程设计器,点击【创建】按钮 注意:流程中需要获取关系类型的字段(如:O2O、O2M、M2O或M2M),这种类型都是复杂的对象字段,除关联字段(一般为ID)以外的字段,需要通过【数据获取】节点单独获取【关系字段】的对象数据。所以在流程设计中经常会用到【数据获取】节点 左上角编辑流程名称为【导购邀请下单触发流程】,点击第一个【触发】节点,触发方式选择模型触发,模型选择【导购邀请下单】,触发场景选择【新增数据时】,点击该节点的【保存】按钮 点击流程图节点间的【+】图标选择增加【获取数据】节点,或者拖动左侧物料区【获取数据】到特定的【+】图标 点击【获取数据】,在右侧属性面板中设置【获取数据条数】为单条,选择模型为【导购】,点击【筛选条件】的【{X}】图标,进行数据获取的条件设置 选择条件字段为【ID】条件操作符为【等于】,条件为变量的导购字段的ID。当上下文只有一个变量时默认不需要选择,这里默认的是【触发[导购邀请下单记录]】,设置好以后点击确认,回到属性面板设置【未获取到数据时执行方式】为【终止流程】,并点击节点【保持】按钮 再增加一个【获取数据】节点,在右侧属性面板中设置 a. 【获取数据条数】为单条,选择模型为【会员】 b. 点击【筛选条件】的【{X}】图标,进行数据获取的条件设置,选择条件字段为【ID】条件操作符为【等于】,条件为变量【导购邀请下单记录】的会员关系字段的ID字段。因为上下文中存在多个变量时需要选择对应变量,跟获取导购数据有点区别,在获取导购数据时,上下文中只有此次【导购邀请下单记录】所以不需要选择对应变量,设置好以后点击【确认】按钮 c. 回到属性面板设置【未获取到数据时执行方式】为【终止流程】 d. 最后点击节点【保持】按钮。…

    2024年5月23日
    1.7K00
  • 7.1 设计器总览

    设计器转为非专业研发设计,在Oinone3.0版本中已经完成元数据完整在线化,真正做到低无一体。对于设计器的定位我们开篇就介绍过,它是LCDP的产品化呈现,是冰山露在外面大家看得到的,核心还是在LCDP本身。我们先目睹下设计器的一些产品页面,如您有想体验,可以在Oinone官网注册 模型设计器 Oinone以模型为驱动,当有模型、数据字典、数据编码等设计功能,我们就可以完整地定义产品数据模型,模型设计器整体呈现区别于普通ER图,以当前模型为核心视角展开,可以点击关联模型切换主视角。这样的好处在于突出当前设计,聚焦设计本身。同时模型上预留了几个核心入口如:分类管理、继承拓扑图、页面设计、逻辑设计等。另外我们在体验上区分了专家模式和经典模式,顾名思义,专家模式的功能会更加丰富,对专业知识的要求也会更高。专家模式下一般会增加一些跟业务无关的配置如:索引设置等调优行为 逻辑设计器 从图灵完备的角度上说,要支持功能越完备,使用越复杂。我们优先从图灵完备的角度出发,所以我们第一版逻辑设计器相对比较复杂,第二版本规划中会类似模型设计器推出专家版和经典版。 界面设计器 界面设计器第一版会先支撑后端页面在线自定义,后边将陆续推出前端页面、多端能力。为了支持多端和2C页面的设计,我们对前后端协议做了比较大的改造。目前设计器已经支持完全基于V3的前后端协议。 数据可视化 数据可视化支持从内部系统模型获取数据内容后,根据业务需求自定义图表,目的是为企业提供更高效的数据分析工具。 与市场同类产品相比,我们的数据可视化产品:不需要前置维护数据源、进行数据转换;可智取业务系统模型,系统自动解析选择的模型、接口、表格中的字段后进行数据分析;降低对数据分析人员研发能力要求的同时,也提升了数据分析的效率。 流程设计器 Oinone流程设计器为业务流程和审批流程提供了可自动执行的流程模型:通过定义流转过程中的各个动作、规则,以此实现流程自动化。在Oinone流程设计器中,流程可以跨应用设计,不同应用的模型之间可以通过同一流程执行。

    2024年5月23日
    1.5K00
  • 1.4 Oinone对软件特性的思考

    我在个人的微信公众号上《浅谈企业IT架构的十年困局》一文中写了“企业或者软件公司在工程领域都关注哪些特征,而这些特征又应与具体研发人员的个体能力无关”的相关内容。收到很多业内人士的留言,也引起了很多同行的共鸣,所以今天在这里也打算针对这个话题,跟大家再做个深入的探讨。 一、首先为什么强调要跟研发个体能力无关 我们先来看一个故事: 轮扁是春秋时期齐国的木工,齐桓公召其入宫打造物件。有一天,齐桓公在堂上看书,轮扁在堂下用椎、凿等工具做车轮。 齐桓公看书看到得意处,不由得读出声来。轮扁听到读书声,想了想,放下手里的工具,走上堂来,在齐桓公面前几步远的地方停下,恭恭敬敬地说:“请恕臣斗胆问一下,君王读的是什么书?”齐桓公没想到这个老木匠会走上堂来,倒有点意外。不过看在他年纪大的份上,倒也不去斥责他,就回答说:“寡人读的是圣人写的书。”轮扁问:“圣人还在吗?”齐桓公说:“已经死了。”轮扁说:“这样看起来,君王所读的,不过是古人的糟粕而已!”齐桓公勃然大怒,说:“寡人读书,你一个做车轮的怎么敢议论?你说,这书上怎么会是古人的糟粕?说出道理便罢,说不出道理便难逃一死!” 轮扁不慌不忙地说:“臣是根据臣所从事的活计而明白这个道理的。砍削轮子,榫头做得宽了则松滑而不牢固,做得太紧就必然涩滞而安不进去,臣制作的榫头松紧适宜,是因为心里怎样想的手便怎样去做。然而尽管所需要的分寸度数心里都明白,要把它用言辞表达出来却实在不可能,全靠自己手与心的配合。所以,臣无法将其中的奥秘传授给儿子,臣的儿子也无法从臣这里学到其中的奥秘。因此,臣如今七十多岁了,还只好亲手去干制作轮子的活。这样看来,古人之道的精华都已随着古人死去而无法传世,那么君王所读的,不就是古人的糟粕了吗?” 这就是著名的成语故事——轮扁斫轮,出自《庄子·天道》。庄子通过轮扁的言论,深刻地揭示了高妙之技的难以言传。 而当我们转换视角,在企业数字化转型领域,无论是软件公司还是甲方IT团队,核心上是应用级开发需求,更多的精力应该放在业务场景理解、需求把控以及业务系统实现上。但往往在一个项目进入研发之前,会花很大力气在技术架构设计、技术栈选型、通用能力对接、扩展点设计这些跟业务场景无关的技术事项上,且需要高级别的架构师来主导。大部分情况下,架构师会选开源框架来实现,慢慢沉淀为企业的研发标准体系,所以底层架构的能力往往依赖架构师个人能力。不禁发现他们与轮扁有着异曲同工之处。架构师所积累的个人经验和技术能力,往往难以通过简单的手把手教学、技术评审会完全传递给团队中的其他成员。即使有所传授,其效率也可能仅达到50%,并且随着团队成员数量的增加,这种效率还可能持续递减。因此,我们需要更多地依赖于技术手段,将架构师的经验和能力固化下来,形成一套可复制、可推广的标准技术产品。这样,每个团队成员都能够通过学习和运用这些技术,达到至少70%的传递效率,从而确保团队整体技术水平的稳步提升。这也正是开篇所强调的,企业或软件公司在工程领域所关注的特征,应当与具体研发人员的个体能力相剥离,而更多地依赖于标准化、系统化的技术手段,来确保团队整体的高效运作。 二、软件公司在工程化领域都关注哪些特征 接下来,我将从技术角度深入剖析设计初衷和技术实现原理,以展现技术公司应当“被标准化的特征”究竟长什么样。 先做个名称解释,下文中涉及“标品”、“升级”、“扩展逻辑”,这是站在软件公司角度出发描述的,如果是企业内部可以把标品理解为特定业务应用平台,升级则是业务应用平台的正常规划迭代,扩展逻辑理解为脱离平台发展的临时性需求。 1. 可逆计算 可逆计算,在应用上的特征图 场景:调查发现企业研发至少有40%的精力在跟各条业务线的团队在评审项目需求,判断需求是否合理。而且业务线对需求完善时间要求紧,每天盯着研发进度,经常问“这个需求什么时候支持,我们等着用”。导致产研部门的研发抱怨产品节奏乱,无法按照自身节奏进行迭代,被项目推着走,没有时间思考,人手不足,加班多,工作压力大…… 价值:该特性很好的规避了研发因为时间紧迫,写的一些临时代码腐蚀核心业务系统。它需要做到不论从数据模型、业务逻辑、交互展示都能有扩展能力,并且这些扩展能力与个体研发无关才行。它同时所描述的也是一个具备差量计算能力的软件架构模式,它允许用户通过添加或移除扩展包来定制标准应用,同时保持应用的可逆性和独立性。这种架构模式的核心优势在于其灵活性和可维护性,使得应用的定制和恢复变得简单而高效。 技术原理:它所描述的是一个基于元数据驱动和差量计算的软件架构模式,它允许用户通过添加或移除扩展包来定制标准应用,同时保持应用的可逆性和独立性。这种架构模式的核心优势在于其灵活性和可维护性,通过元数据来驱动应用的构建和变更,使得应用的定制和恢复变得简单而高效 在这种架构中,元数据起到了至关重要的作用。元数据是关于数据的数据,它描述了数据的结构、属性、关系等信息。在软件应用中,元数据可以用来描述应用的组件、功能、配置等信息。通过元数据驱动应用可以根据元数据的描述来动态地构建和配置自身的功能和结构 差量计算则是实现应用可逆性的关键。当添加或移除扩展包时,系统会根据扩展包中的元数据与标准应用的元数据进行差量计算,确定需要添加或移除的功能和组件。这种差量计算可以确保在添加扩展包后,应用能够保持原有的功能和稳定性,同时新增扩展包带来的新功能,而在去除扩展包时,应用能够恢复到原始的标准状态,不会留下任何冗余或冲突的代码和配置。 为了实现这种架构模式,元数据注册表和分布式部署能力是非常重要的。元数据注册表需要能够存储和管理大量的元数据信息,并且提供高效的查询和更新机制。分布式部署能力则能够确保应用在不同的环境中都能够稳定运行,并且能够快速地响应扩展包的添加和移除操作,即差量(扩展包》可独立存在又相互作用。 总的来说,这种基于元数据驱动和差量计算的软件架构模式为应用的定制和恢复提供了强大的支持,使得应用能够根据不同的需求进行灵活的定制和扩展。同时,它也提高了应用的可维护性和可靠性,降低了开发和维护的成本 2. 协同演进 协同演进,在应用上的特征图 场景:它所描述的场景是一个复杂的软件升级过程,其中涉及了标准应用的升级以及用户个性化扩展的保留。通过面向对象的方式扩展标准应用的功能,可以在升级过程中保持用户自定义逻辑的完整性,并同时集成新版本中的新特性。 价值:很多号称产品型的软件公司,在交付客户项目的时候,都是从标品复制一个分支,然后客户个性化直接在这个分支上改。这种模式会带来两个问题: 是当客户数量变大,每个客户的版本都不一致,维护成本很高; 是当标品升级带来的新特性无法复制给客户,导致客户满意度下降甚至流失。协同演进就是要解决这个问题。 技术原理:它需要在第一个差量计算的特性基础上才能得以完成,同时在这种升级能力中,元数据驱动和模型驱动是关键所在。元数据驱动确保了应用能够理解和处理不同版本之间的变化,包括功能的增删改以及结构的调整。模型驱动则提供了描述和管理应用结构、组件和行为的能力,它不仅能够描述模型间的关系,还能够支持面向对象的特性,如继承、重写和重载等。 具体来说,当标准应用从V1升级到V2时,元数据驱动机制会首先识别和分析两个版本之间的差异。对于用户应用1中已经扩展的A功能,由于采用了面向对象的方式进行扩展,因此在升级过程中,A+逻辑作为A功能的重写或重载版本会被保留下来。同时,V2版本中新增的B功能也会被集成到用户应用1中,因为它是作为标准应用的新特性而存在的。 这种升级能力的实现依赖于一个强大的元数据注册表和模型管理能力。元数据注册表需要能够存储和管理不同版本应用的元数据信息,包括功能、组件、结构等。模型管理能力则需要能够解析和应用这些元数据,以生成正确的应用结构和行为。同时,还需要一套高效的升级机制来确保升级过程的平滑和可靠。 总的来说,通过元数据驱动和模型驱动的结合,可以实现标准应用的平滑升级,同时保留用户个性化扩展的完整性。这种能力对于提高软件的可维护性、可扩展性和用户满意度具有重要意义 3. 公民研发和专业研发共同参与 专业研发与公民研发共同参与,在应用上的特征图 场景:它所描述是在应用开发的整个生命周期中,专业研发专注在标品的长期规划与迭代,当出现临时性的需求或者应急性的辅助场景则由非专业人士进行即公民研发方式进行。这种模式下,专业研发可以按照规划有节奏的迭代产品,做更高级的事情,不至于忙于应对临时性的事务没有深度思考,更加避免了因为临时代码堆积导致产品从内部腐化。同时利用独立的扩展逻辑包和无代码方式解决了业务的紧迫感,毕竟业务需求的合理性是很难争论出高低的。它在前两个特性基础上让研发效能进一步得到释放。 价值:它的本质是,在专业研发在以低代码的方式下实现应用,并通过无代码的方式,快速扩展逻辑功能和创建辅助性应用。整个过程无缝衔接,我们给他取个名字专业名称叫:“低无一体”。它大大降低了技术门槛,使得专业和非专业的研发人员都能参与到应用扩展和定制中来。此外,它还提高了业务响应能力,使得企业能够更快速地适应市场变化和客户需求。 技术原理:它的核心要求就是元数据在线,元数据在线能力是指能够实时地、在线地管理和操作元数据,这种能力为企业或组织带来了诸多优势。通过无 代码的方式,用户可以更加灵活地进行应用的个性化扩展,以应对各种应急性需求,从而显著提升业务的响应能力。此外,元数据在线管理还确保核心应用、核心应用扩展以及辅助应用都是基于一套统一的技术体系构建的,这为不同角色的用户(包括专业和非专业的研发人员)提供了多样化的参与方式。同时,元数据在线管理需要符合开闭原则,这确保了系统的稳定性和可扩展性,使得新的功能或需求可以通过添加新的元数据或配置来实现,而非修改现有系统。 这种低代码开发与无代码一体化的优势在于,它大大降低了技术门槛,使得专业和非专业的研发人员都能参与到应用扩展和定制中来。此外,它还提高了业务响应能力,使得企业能够更快速地适应市场变化和客户需求。 总之,从用户应用到业务实施的过程通过元数据在线得到了优化和升级。低代码开发与无代码一体化的优势使得整个过程更加高效、灵活和易于维护,为企业带来了显著的价值和竞争优势。 4. 基于平台级别的AOP能力出现反向集成 反向集成,在应用上的特征图 场景:平台级别的AOP(面向切面编程)能力允许开发者在应用程序的特定点“切入”额外的逻辑,而无需修改原有的业务代码。这种能力特别适用于横向追加平台逻辑,即在多个不同服务或功能点插入通用的处理逻辑,如日志记录、权限检查、审计、多租户、多语言等。过往在微服务架构中,这些能力都需要业务系统各自主动去对接,有了平台级别的AOP能力,则这些通用能力可以反向为所有业务系统增加特性能力,无需业务系统研发感知。这种现象我们称之为“反向集成”,能让业务研发更加专注在业务研发本身,不需要关心与业务无关的通用功能上。 价值:AOP的核心思想是将这些横切关注点(cross-cutting concerns)从业务逻辑中分离出来,使得业务代码更加清晰和专注于其核心功能。在平台级别的AOP中,标准化协议是实现这一能力的关键。平台具备统一的入口和扩展能力是非常重要的,因为它允许开发者在不修改现有代码的情况下添加新功能或修改现有功能的行为。这种能力对于快速响应业务需求变化、减少维护成本和提高代码质量都是非常有益的。 技术原理:标准化协议确保了不同组件之间的通信与语义是统一的,从而使得AOP能够更容易地实施。例如: a前后端通信要标准协议(与端无关): 这意味着无论前端是使用Web、移动应用还是其他类型的客户端,后端服务都应该能够以一种标准的方式与之通信。 bORM层要有标准协议(与数据库无关): 对象关系映射 (ORM)层应该提供一个标准的接口来与数据库进行交互,这样无论底层使用哪种数据库(如MySQL、PostgreSQL、Oracle等),上层的业务逻辑都不需要改变。 cRPC需要标准协议(与Dubbo和Spring Cloud无关): 远程过程调用 (RPC)应该遵循一种标准协议,以便不同的服务可以无缝地进行通信,而不受特定框架 (如Dubbo、Spring Cloud等)的限制。 d所有逻辑调用统一fun调用: 这意味着平台上的所有功能调用都应该通过一个统一的入口点(如一个函数或方法)进行,这样AOP就可以在这个入口点切入额外的逻辑。 总的来说,平台级别的AOP能力通过标准化协议和统一的调用入口,为开发者提供了一种强大而灵活的方式来管理和扩展平台的逻辑功能。 5. 应用研发与部署无关 应用研发与部署无关,在应用上的特征图 场景:现在研发在选择部署方式的时候往往会选择分布式部署,或者你的客户招标需求里就写着“微服务”,构建一个微服务系统并不是一件容易的事,构建的复杂度远远超过单体系统,开发人员需要付出一定的学习成本去掌握更多的架构知识和框架知识。服务与服务之间通过HTTP协议或者消息传递机制通信,开发者需要选出最佳的通信机制,并解决网络服务较差时带来的风险。另外服务与服务之间相互依赖,如果修改某一个服务,会对另一个服务产生影响,如果掌控不好。会产生不必要的麻烦。由于服务的依赖性,测试也会变得很复杂,比如修改一个比较基础的服务,可能需要重启所有的服务才能完成测试。前段时间有篇很火的文章,《从微服务转为单体架构、成本降低 90%!》,无论是选择何种部署方式,我认为这都应该跟应用研发无关。 价值:应用研发与部署无关的理念确实为现代软件架构带来了显著的优势,它使得研发团队能够专注于业务逻辑和功能实现,而无需担心具体的部署细节。这种分离带来了灵活性、效率以及成本效益的多重提升。应该采用一种同时支持分布式和单体部署、且可以自由切换的架构,我们称之为可分可合。 首先,可分可合的能力使得系统能够灵活应对业务量的变化。在业务量小的时候,可以采用单体部署的方式,简化部署流程,降低初期成本。随着业务量的增长,系统可以平滑地过渡到分布式部署,通过拆分微服务来提高系统的处理能力和扩展性。这种灵活性确保了系统既能满足未来发展的需要,又能兼顾当下的成本效益。 其次,应用级别扩容的能力使得系统性能不再受限。通过增加微服务实例或调整资源配置,系统可以按需进行扩容,从而确保在业务高峰期或突发流量下仍能保持稳定的性能。这种按需扩容的方式不仅提高了系统的可靠性,还降低了运维成本。 技术原理:核心在于逻辑调用的统一执行和智能判断。通过如funEngine这一统一调用引擎,系统能够智能地选择最适合当前业务场景和性能需求的fun调用方式。无论是同步调用、异步调用还是基于消息队列的调用方式,funEngine都能进行智能决策,确保调用的高效性和可靠性。这种统一调用的方式简化了开发过程,降低了开发难度,同时也提高了系统的可维护性和可扩展性。 此外如果作为低代码或者其他研发平台来说。被集成特性也是实现该特性的关键所在。它提供了一套标准化的接口和协议,使得其他系统或应用能够轻松地与其进行集成。这种平台框架化的特性能够作为一个统一的、可扩展的框架来支撑整个系统的运行。 综上所述,具备可分可合的能力、应用级别扩容以及逻辑调用的统一执行和被集成特性,共同构成了应用研发与部署无关这一核心特性。该特性使得软件系统能够灵活地应对业务变化,实现高效、可扩展和可维护的运行,从而满足客户的长期发展需求并兼顾当下的成本效益。

    2024年5月23日
    1.7K10

Leave a Reply

登录后才能评论