面向AIGC的开发组件体系设计-Toy模板网

这篇具有很好参考价值的文章主要介绍了面向AIGC的开发组件体系设计。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

我们知道，AI大模型可以通过提示来编写代码，因为它经过了GitHub中的许多优秀代码的训练。但是这些代码都是由不同的优秀程序员所编写，同一种功能有许多不同的实现方式，基础的组件和框架也是为人类程序员开发和设计的。

也就是说AIGC虽然很优秀，但程序员拥有的缺点它都具有。也许我们可以针对AIGC的特点，为其专门设计合适的组件体系来进一步提高AI与程序员沟通的效率，从而充分发挥AI大模型的能力。

这里主要面向信息管理系统的开发，对其应用的组件体系进行分析。先讨论一下面向AIGC组件体系的设计原则，再对常用的前后端组件进行梳理。后端采用的语言为Java语言，框架是Spring框架，前端为JavaScript，采用Vue/React框架。

面向AIGC的开发组件体系设计

设计原则

1、前后端一体化

显然对于AI大模型，必然是拥有全栈能力。目前，基于Web的信息管理系统的主要开发技术都采用的是前后端分离，前后端采用独立的语言和技术框架，交互通过Http的服务接口进行定义。

这里的一体化不是对技术和框架进行统一，而是在前后端分离的基础上，对数据和逻辑进行统一。采用约定大于配置的原则，将前端和后端组件交互的数据和接口进行统一：统一数据模型，统一接口定义，统一使用方式。

前端组件的使用依赖于后端的框架体系，后端的组件能够为前端提供更加高效统一的数据模型和服务接口。

这样虽然从实现上分离，但是在内在逻辑上保持一致，从而可以有效地避免重复设计，有利于减少代码量和保持代码可读。同时将软件的关注点不再拘泥于前端和后端，而是技术和业务，尽可能的封装技术，简化业务实现。

值得说明的是，对于大多数的软件系统，代码量是越少越好，而不是越多越好。

2、面向对象机制

面向对象原则也是组件设计的重要策略。面向对象从一开始就是简化编程思路，封装实现细节的重要方式。可以整个组件体系都采用面向对象的设计方式，对属性、方法和样式进行最简的优化设计。

后端的技术选项通常都采用面向对象的编程语言，如Java，C#，Python，Go等。以Java为例，主要的类库框架都是以面向对象为主。

继承和多态是面向对象的两个重要特性，通过继承可以有效的减少冗余，对组件进行更高维度的抽象。通过多态可以增加子类实现的灵活性，兼顾了易用性和灵活性的平衡。

而以JavaScript为主的前端技术，由于JavaScript本身是一门动态语言，虽然可以模拟面向对象的特性，但是由于过于灵活，一直作为操作HTML的DOM树的辅助语言存在，很少用到面向对象的设计，以JQuery为代表达到了顶峰。

随着以React、Vue、Angular等前端框架的出现，面向对象的设计再次被重新重视，特别是React框架，前端的组件实现可以被完美地面向对象化，继承和多态以非常自然的方式得到体现，这使得前端组件体系用面向对象的设计实现成为可能。

参考很多C/S架构的组件体系设计，如C#的WinForm和WPF组件框架，C++的QT等，这些组件的设计思路和架构都具有很多的借鉴价值。

3、无以复减的属性和方法

无以复减的原则就是对组件的属性和方法要尽可能的少，同时尽可能的简单，屏蔽其中的技术细节。就像汽车一样，留给用户的只有方向盘，油门、刹车和后视镜，用户无需知道发动机的原理，也无需知道更多的技术实现细节，只专注于业务目的地即可。

要做到更少的属性和方法就需要对组件进行合理的分类。以前端组件为例，原生的HTML组件的属性重复性非常高，同样的场景可以说使用任意组件都有无数种实现方式。这一方面是历史原因，另一方面也是为了更多的灵活性，这也符合互联网应用的特点。

但是对于信息管理系统，我们应更关注业务的复杂性，减少技术实现的多样性，所以对组件进行分类封装。目前很多组件框架的分类方式还是以互联网的思维方式为主，从组件的显示特点进行分类，如导航，按钮，图表，表格，录入等等。这样的分类虽然直观，组件的属性和方法延续了原生的设计并不能减少，而且对于信息管理系统还是存在一定的困惑。

我们从组件和后端数据模型的内在一致性出发，对组件进行重新分类，分为显示组件，编辑组件和布局组件。属性和方法更偏重于与后端服务接口和数据模型一致，这样就可以有效的统一前后端设计，减少组件本身的实现细节，更多的关注于业务。

同时无以复减也代表了少即是多的理念，虽然组件的属性和方法变少，但组件的数量变多，面对的业务变多，从而有更多的业务实现可能性。

4、基于数据类型分类

组件的分类规则通常是以功能作为依据。对于一些功能特殊的组件往往难以划分，造成分类复杂而且不够清晰。这里主要根据数据类型对组件进行分类，前后端采用一致的数据模型，后端组件通过继承“基础数据模型”和“基础服务模型”，提供了一致的对外服务接口。

返回的数据类型主要有三种，分别为：单值，键值和数组。对应于数据库设计中，数据表的某个属性值，数据库的单条记录和数据表的多条记录。在实体映射中，对应一个实体类的属性，一个实体的实例和一个实体的数组。

前端组件根据数据模型的类型分为三类：编辑组件，显示组件和布局组件。编辑组件对应于对象类型数据，相当于数据库表中的单条记录，如输入类组件主要是对单值进行录入，选择类组件对键值数据类型进行选择；显示组件对应于列表类型数据，相当于数据库表中的多条记录，如表格的数据源。布局组件则不对应任何数据类型。

因此，根据单值，键值和数组这三种基础数据类型，既统一了前后端的交互格式，同时也对组件的分类进行划分，使得组件的边界更加清晰，组件的使用也更加方便。

5、合理的设计模式

在J2EE的技术规范和指南中，一般分表现层，控制器层，业务逻辑层，数据访问对象层和领域对象层。但是在具体的使用过程中，往往非常冗余，且对于领域模型的表达也非常不清晰。

而传统的三层架构来源于经典的设计模式MVC模式，即模型层，视图层和控制层，通过对MVC的改造，可以使得组件的职能更加单一，具有“高内聚低耦合”的特点。

后端组件分为模型层和控制层。模型层对数据进行建模，负责数据库的操作和业务逻辑的处理；控制层即服务层，一方面负责提供服务接口与前端组件进行交互，另一方面通过调用模型进行数据库操作和业务逻辑处理。前端组件则为表现层，只负责用户的交互和数据展示。

反过来，我们将表现层拆解出各种前端组件，将业务逻辑处理和数据访问功能进行合并为领域模型。通过对业务的不断分解，进一步设计出整个后端组件体系。

6、开放集成能力

开放性是组件设计的重要原则，应该是保证在一定规则之下的。规则过于严格，会导致开放性不足；但过于宽泛，则过犹不及。

在很多拖拉拽的可视化设计系统中，组件的设计往往会比较复杂，需要顾及整个可视化体系。虽然在使用上比较简单，但是扩展性不足，能够达到的效果也受限于系统提供的组件。而在其他一些快速开发框架中，由于缺少统一的设计规则，组件以堆叠的方式组合到一起，也会造成难以修改并导致各种问题的出现。

因此需要合理的设计才能保证组件的开放性，尽可能利用成熟的组件生态体系，如React、Vue等框架，利用统一的设计原则对组件进行封装，规范组件的使用，同时支持对原生组件的扩展，保证原生组件的完整性和可用性。