DZone>Web Dev Zone>用一个命令创建可定制的数据库应用系统
用一个命令创建可定制的数据库应用系统
一个命令就可以使用声明性的规则创建可执行的系统；使用Python和标准的IDE就可以直接进行定制。
通过
-
1月25日，22 - Web开发区 -教程
喜欢 (10)
评论
保存
鸣叫
2.90K浏览次数
加入DZone社区，获得完整的会员体验。
现在，新的开源技术使你能够通过一个命令来创建可定制的、模型驱动的系统，而不是大量繁琐的、重复的代码。
ApiLogicServer create --project_name=/localhost/ApiLogicProject --db_url=
这可以直接从你的数据库中创建一个工作的、可定制的系统。
- 一个基于React的管理应用程序，用于后台数据维护和终端用户协作。
- 一个带有Swagger的API，用于定制应用开发和应用集成。
- API执行后台 逻辑，使用独特的类似电子表格的规则，明显比代码更简洁。
在本教程中，我们将探讨。
- 关键要求
- 创建过程
- 架构
- 创建的系统
- 定制化
- 技术考虑
关键要求。快速和简单是不够的
作为开发者，我们认识到并理解对业务敏捷性的需求，以快速创建和迭代系统。 当然，让一个运行中的系统拥有一个命令--准备好让利益相关者参与--是一个伟大的开始。
但这是不够的。 我们都见过这样的系统，它提供了一个良好的开端，但却不能使我们完成项目，或维护它。本节列出了一些关键要求。
可扩展的自动化
尽管自动化是可取的，但让所有行为都自动化是不可行的。 这甚至是不可取的--完全的自动化需要1000个选项。
正确的方法是可扩展的自动化。下面描述了一些关键的要求。
标准语言，工具（IDEs，源代码控制）
自动化需要创建基于文件的项目，可以利用熟悉的工具，包括。
- 标准语言
- IDEs，用于代码编辑和调试
- 源码控制
例如，将关键行为存储在数据库/云设置中，使得项目难以管理。
模型，而不是代码
定制不应该建立在改变生成的代码上。 即使是我们在这里介绍的一个小应用，也涉及到几百到几千行相当复杂的代码Python、JavaScript、HTML等，而生成的代码往往难以阅读。
事实上，生成代码是不明智的，因为当你需要理解它或定制/扩展它时，它极大地降低了抽象水平。 理想的情况是，创建过程创造出模型--简单地理解、定制和扩展，无需培训。
现代架构。API、逻辑、可扩展的容器
现代系统需要一个API来支持移动应用和应用集成。 因此，任何自动化创建必须包括API。
API必须作为服务运行--而不是*"电线上的JDBC"*，但包括业务逻辑的执行，如多表派生和约束，以及发送邮件或信息等行动。
最后，现代系统利用容器，如Docker，进行隔离开发和部署。
业务逻辑--自动化，而不是 "你的代码要放在这里"
后台逻辑往往是系统的一半。 低代码方法要么不解决这些逻辑，要么在UI事件上采用 "你的代码在这里"。 这有两个明显的缺点。
- 抽象性差--这种方法导致了大量的逻辑代码；我们将在后面看到一个简单的需求是如何在数百行的代码中爆炸的。
- 不正确的分区--UI按钮上的代码很难重复使用，导致重复、不一致的结果和昂贵的维护费用。
有效的自动化需要我们。
- 提供自动化，为前端和后端保持一个高水平的抽象。
- 将逻辑从UI事件中划分出来，这样它就可以自动重复使用--在所有的应用程序中自动重复使用逻辑。
创建过程
上面的create 命令通过反省你的数据库来创建一个可执行的项目，由--db_url 参数指定。上面的空白值使用预先提供的样本数据库（Northwind - 客户、订单等）。要使用你自己的数据库，请指定一个SQLAlchemy URI（数据库类型、服务器、模式、凭证等）。
你可以在你的IDE中打开所创建的项目，进行定制和调试。项目元素是文件，所以你可以用你现有的源码控制、代码管理等工具来管理项目。我们将更仔细地检查该项目，下面。
现代架构 - n-tiered, API-Driven
该系统通过pip安装，或（如上图）通过docker容器来安装。 它作为一个标准的多层应用程序执行（如下图所示）。
- 管理应用的实现不是大量复杂的JavaScript和HTML，而是一个 模型 *- 对应用程序应该做什么的描述，而不是如何做。*在这种情况下，模型被表示为一个易于编辑的YAML文件，位于你的
ApiLogicProject. - 管理应用程序在浏览器中使用 react-admin 执行。 它使用自动创建的JSON:API（SAFRS）来读取和写入数据。
- 该API使用SQLAlchemy来读/写数据。 维护数据库完整性的业务逻辑是在
declare_logic.py。 这个逻辑表达了多表派生和约束，以及发送电子邮件或消息等动作。 这也是一个由规则和Python组成的模型文件，我们将在下面看到。 它被逻辑库规则引擎使用，它监听SQLAlchemybefore_flush事件并执行你的逻辑。
请注意，这种 "带逻辑的API "的方法对所有的开发（例如，自定义应用程序和应用程序集成）都很有价值，因为它将共享的逻辑考虑在内并确保其重复使用。
图1 - 架构
创建的系统
让我们检查一下从create 命令中建立的系统。
模型，而不是代码
下面是创建的ApiLogicProject，在VS Code中打开。 树上显示了一个标准的、基于flask的项目。 除了通常的配置文件外，关键文件如下所示。
expose_api_models.pyl：这个模型文件定义了你的API；对于你公开的每个表，api引擎提供了数据读写的端点。admin.yaml：这个模型文件定义了你的管理应用程序。 至于API，它很容易理解和修改models.py：这些类（例如，客户）被SQLAlchemy用来定义你的数据模型。 它们能够在IDE中实现代码补全。api_logic_server_run.py呼叫中心：这是你实际执行的类，用于设置API和启动服务器。
所以，这就是对所创建的模型文件的快速浏览。 现在让我们来看看它们的作用。
React管理应用程序 - 多页，多表，自动连接
如下图所示，每个表都创建了两个页面：一个列表页和一个展示页。 因此，在我们的Northwind例子中，我们的create 命令产生了一个30页的应用程序。
列表是任何应用程序的一个关键方面；它们支持多字段搜索，通过点击列标题进行排序，以及为良好的大结果性能进行分页。下图说明了对多页应用程序的支持：点击客户可以放大到其显示页面。
页面是多表的，自动包括相关的数据，如已下订单。同样，你可以点击一个订单来查看它的细节，包括其订单细节的列表。因此，你可以在管理应用程序中 "行走数据库关系"。
观察订单的雇员（销售代表）。它是一个自动连接。每个订单都有一个外键EmployeeId ，这个数字对用户来说没有意义。 所以系统自动加入了Employee.Name 。还提供了弹出对话框，以查看全套的相关数据。
更新支持--查询、逻辑
该更新包括对Lookups的重要支持，通过名称而不是Id来填写外键。在下面的截图中，OrderDetails通过ProductId ，与他们的产品有关。系统不仅提供了自动连接，而且还提供了查找功能来过滤/选择一个产品（Chai、Chang等）；系统填写了外键。
保存按钮启动了重新计算订单金额总数的逻辑。这个逻辑是通过一些规则--不是代码--实现的，我们很快就会看到。
**主要收获：**不是一个逐页的 "低代码 "屏幕画家，但单一的create 命令建立了一个完整的、多页/多表的应用程序。
API - 使用Swagger
该系统还自动创建了一个API，用于应用程序，以及自定义应用程序和应用程序的集成。 该API支持过滤、分页和相关数据访问。
我们可以通过自动创建的Swagger检查API。每个表都有一个端点，有检索和更新的动词。
**主要收获：**创建一个单一的 "hello world "端点并不难，甚至可以返回一些SQL数据。对于create 命令来说，为每个表建立端点，并带有过滤、排序、分页和相关的数据访问，则是另一回事。
定制--Python和你的IDE
到目前为止所展示的一切都是从创建命令中自动构建的。 这是一个很好的开始，但是能够利用标准语言和工具来定制系统是非常关键的。
create 命令建立了一个ApiLogicProject，你可以在你的IDE中进行自定义，比如PyCharm或VS Code。下面显示的是VS Code中的项目，该项目是建立在自定义的基础上的：模型、API、逻辑和应用程序。预建的配置可以使用Docker或pip安装，也可以使用IDE工具，如代码编辑器和调试器。
下面的章节简要介绍了对模型、应用程序、API和逻辑的定制。
自定义应用程序 - 列的顺序和标签
如上所述，管理应用程序的实现不是大量复杂的JavaScript和HTML，而是一个 ***模型--对应用程序应该做什么的描述，而不是如何做。***在这种情况下，模型被表示为一个易于编辑的YAML文件，位于你的ApiLogicProject 。
上面的左下角窗格显示了YAML文件。 重新安排列的顺序，指定标签，以及进行其他基本的改变是很容易的。
自定义应用程序 - 使用API/逻辑
这种即时应用程序适用于即时协作，以及后台数据维护。 对于面向客户的定制应用程序，使用你选择的工具与API结合起来进行数据检索和更新。
你的自定义应用程序的操作方式与上面图1-架构中的管理应用程序完全相同。重要的是，这个API。
- 执行你的业务逻辑（如下所述），具有显著的 简洁性。
- 通过将逻辑封装在API中，而不是每个UI控制器中，提供自动的重复使用-- 提高质量和简化开发。
自定义API--添加端点
我们还可以定制API。 下面这段代码（第124-130行）定义了一个新的端点，addOrder 。第108-119行是用来生成Swagger样本数据的。
这段代码很短，因为所有的推导和约束逻辑都是在规则中声明的，我们一会儿就会看到。这些规则被自动重复使用，无论事务是来自于创建的API，还是来自于我们的定制。
你可以使用你的IDE来调试你的定制。 现代集成开发环境使你能够检查变量、设置手表、逐步执行等。 在下面的图中。
- 我们使用Swagger（右窗格）为我们的自定义端点提交一个由一个订单和一组订单细节组成的订单。
- 我们在自定义端点第124行设置一个断点。
声明逻辑以处理系统的后端部分
对于ApiLogicServer所针对的事务性系统，通常后端逻辑几乎是应用程序的一半：多表推导和约束，以及发送邮件或信息等动作。
问题是，一个简单的5行的 "鸡尾酒餐巾纸 "规范会爆发出200行的代码，如下所示。
你可以使用ApiLogicServer来代替编写所有的代码。 声明为多表派生和约束制定类似电子表格的规则。 下面显示的这5条规则（第49-66行）代表了与200行Python相同的逻辑--是上述鸡尾酒餐巾纸规格的可执行表示。
经验表明，规则解决了95%的后端逻辑。 这很有意义：你将系统的后半部分减少了40：1（200行代码/5条规则）。
ApiLogicServer规则引擎在服务器启动时加载这些规则。 它监听SQLAlchemy更新事件，并在API更新发布时自动执行你的逻辑。
执行包括自动化的排序和优化。 在迭代/维护过程中，这种自动化被重复作为你的改变逻辑，所以你在项目的生命周期中继续获得价值。
主要收获：后端逻辑是交易系统的一个关键因素。 它经常被无代码/低代码方法所忽视，或以 "你的代码在这里 "来解决。 ApiLogicServer不仅能在短时间内创建项目，还能让你自定义项目，使用声明性规则，大大增加业务敏捷性。
自定义逻辑。逻辑=规则+Python
在我们的一般方法中，规则也不例外：最大化自动化，但提供可扩展性。 95%的自动化是伟大的，但除非我们能解决最后5%的问题，否则就没有价值。
所以，逻辑不仅仅是规则，也是Python。 下图显示了同样的放置顺序事务，在我们的Python逻辑中停在一个断点上。
- 代码补全在声明规则时很有帮助（第37行）
- 第81行的规则声明了一个事件；箭头所示的是Python事件处理程序 (
congratulate_sales_rep) - 在你的Python代码中，你可以设置断点（第73行），并检查变量（左窗格）。
- 除了调试器，逻辑引擎还创建了一个逻辑日志--它显示了每个规则的执行情况（底部窗格），包括列值和缩进以显示多表链。
**主要收获：**规则是用Python声明的，有代码完成功能。规则可以调用Python代码，并有完整的调试器支持，为执行规则没有自动的操作提供灵活性。
迭代/维护周期--重建命令
除了create 命令，系统还提供了一个rebuild 命令，这样你就可以解决对数据库模式的改变。 这对现有的项目进行操作，保留了定制的功能。
技术考虑
本节总结了技术的关键方面，并回答了我们有时被问到的一些问题。
关键方面。自动化、模型驱动、可定制
也许ApiLogicServer最引人注目的地方是 自动化:create 命令在瞬间建立了一个完整的管理应用和API。 自动化不只是针对客户端--你可以声明 规则来自动重复使用后端逻辑。
但是考虑到从创建命令中建立的东西也是很重要的。 不仅仅是一个你可以在你的IDE中定制和调试的项目......创建的工件是 模型是声明*"*什么，而不是如何"。 这些模型的理解、修改和维护要比大量的生成代码简单得多。
最后，项目是 可定制的- 使用你的IDE、Python和源码控制工具。
低代码/无代码？
ApiLogicServer与许多低代码系统不同。
- **屏幕创建：**与需要你绘制每个屏幕的系统不同，ApiLogicServer自动创建一个完整的多页面应用程序。
- **后台逻辑：**与省略这一要求的系统不同，ApiLogicServer提供了逻辑--用Python可扩展的规则--以极大地减少后台逻辑，并确保其重复使用。
- **架构：**与基于云的系统不同，ApiLogicServer可以在你的桌面、标准服务器和容器中运行。 与在屏幕函数中嵌入业务逻辑的系统不同，ApiLogicServer提供了一个API，封装了逻辑，以便自动重复使用。
- 集成开发环境友好： 与专有的开发环境不同，ApiLogicServer与你的集成开发环境和工具环境自然整合。
- 可视化编程。ApiLogicServer专注于声明性的方法，它提供了比程序性代码更多的进步：自动排序、自动重用、自动依赖性管理。 可视化编程是一种程序化的方法，不能提供这种自动化。
学习曲线？
学习一项新技术是开销，必须与收益进行权衡。 让我们来看看收益和必须学习的内容。
对于事务性系统，收益是相当大的 --create 命令代表了几周或几个月的节省。 规则比代码要简洁得多，更容易维护，而且可以自动重复使用以提高质量。让我们来看看开销。
create 命令不需要特别的 Python 背景，只需要基本的开发和数据库技能。 那就剩下两件事需要学习。Python（如果你还不知道的话），和规则。
定制时需要Python。 重要的是，这不是 "从头开始 "的编码 --create 命令建立了你的项目结构和一个工作系统。 所以你总是在一个工作基础上添加代码--比冷启动简单得多。而且，你需要的基本定制的Python数量在一天左右就可以轻松掌握，特别是考虑到这些例子。
规则当然是新的。 有10条规则，所以学习它们是相当快的。 真正的诀窍是学会 "思考电子表格"--代替代码，声明多个规则来解决一个需求。 这些例子应该有助于钉住关键的模式。 经验表明，2天的时间应该足以提高规则的水平。
自定义应用程序？
管理应用程序为即时创建预先定义的应用程序类型进行了优化，没有试图解决所有可能的UI要求。 API是为自定义应用程序提供的；重要的是，它通过自动重复使用来执行你的业务逻辑，这比在每个UI控制器中嵌入业务逻辑要好得多。
成熟的技术？
这里有大量的创新--应用程序和API的自动构建，以及规则。 这是一个自然的问题，它是否经得起严肃的应用。
事实证明，这实际上是一项成熟的技术。 它始于Wang PACE系统，已安装在6500多个地点。 技术演进在Versata继续进行，有700多个站点，有数十亿美元的IPO，并得到微软、SAP、Informix和Ingres的创始人的支持。 客户为这些产品支付了每台计算机约5万美元。
为什么不是Rete？
有些人问为什么有一个专门的规则引擎而不是Rete引擎。 虽然Rete适合决策逻辑，但由于多表性能不佳，它被证明是交易处理的一个糟糕选择。 特别是，链式聚合 导致了许多高成本的SQL命令。
例如，考虑用一个不同的产品来替代一个订单明细--系统必须重新计算订单总额和客户余额，以确保不超过信用额度。 一个Rete引擎会把所有的订单和它们的所有订单细节加起来，以计算新的余额。
ApiLogicServer中的交易逻辑引擎是专门为解决这个问题而设计的，具有自动剪裁和优化功能。 关键是将逻辑整合到持久化机制（SQLAlchemy）中，使系统能够在更新时比较新/旧值。 这使得系统能够对未改变的数据进行修剪规则，并使用deltas来取代链式聚合，只需一次调整更新。 这已被证明可以将交易时间从几分钟减少到亚秒。
这里的例子假定使用了存储的聚合。聚合是存储的还是虚拟的，这是一个设计选择；改变模式将自动重新优化事务逻辑。这使你能够在项目后期改变你的设计，而不需要重新编码所有的相关逻辑。
总结
所以，你有了它。在片刻之间，你可以创建一个完整的系统，为敏捷协作和近乎即时的迭代做好准备。你可以在你的IDE中定制和调试应用程序、API和逻辑，并使用你现有的源码控制系统来管理它。
我们看到该系统主要是模型--对我们想要的东西的可执行描述，而不是表达如何的详细代码。开始使用、定制和维护要简单得多。而且，它运行在一个隔离的容器中，有利于清洁开发和部署。
要进一步探索它。
- 开源： GitHub网站包含安装说明、样本、文档和教程
- **探索应用程序：**你可以探索这个应用程序和API，在PythonAnywhere上运行
- **视频：**在YouTube上观看这个应用程序是如何构建的
鸣谢
这里的大部分工作都是通过Thomas Pollet的努力完成的。 特别是他在API和管理应用程序背后的工作。我还感谢长期以来的朋友Max Tardiveau的帮助，他指导我度过了一些坎坷的Docker时刻。
谢谢你的阅读!
主题。
规则, python, 数据库应用开发, 数据库应用, 应用自动化, 应用 开发, 应用逻辑, react, api自动化, api builder
DZone贡献者所表达的观点属于他们自己。
在DZone上很受欢迎
评论
