0

如果我有一个简单的数据结构，只需要一个服务（公式）来处理其他表（表单组、字段）中的相关数据。

  1. 如何区分是更新操作还是在结构中插入了新数据的创建操作？（通过类似 id 是否为空？）
  2. 使用一项或多项服务？

数据结构：

{
    "id": 7
    "name": "Formular name",
    "formgroups": [
        {
            "id": 28,
            "formularId": 7
            "name": "General",
            "fields": [
                { "name": "Firstname", "id":107, "formgroupId":28 },
                { "name": "Lastname", "id":108, "formgroupId":28 },
                { "name": "Birthdate", "id":111, "formgroupId":28 }
            ]
        },
        {
            "name": "Address; new group with new fields",
            "fields": [
                { "name": "Street"},
                { "name": "Zip"},
                { "name": "Country"}
            ]
        },
        {
            "name": "Additions",
            "fields": [
                { "name": "First Line"},
                { "name": "Second Line"}
            ]
        }
    ]
}

如果只有一个服务（/formular），我会将整个数据结构发送给它，并且需要区分具有id的元素，因此它将进行更新查询，或者如果没有，则创建与其相关的记录“父母”-id。

在一项服务中这样做会损害单一责任原则。因为我的公式服务中有来自表单组和字段的逻辑。

此外，我不确定之前和之后的钩子是否可以再与羽毛续集关联一起使用。他们可能绕过了。

如果使用多个服务（/formular、/formgroup、/field），请对id进行相同的检查，但客户端应用程序使用 PUT/PATCH 或 POST 分派到每个服务。

补丁/公式/7

补丁/formgroup/28

补丁/字段/108

POST /formgroup （插入公式 id 7 并取回 formgroup id 29 用于下一个字段插入）

POST /field（插入“Street”，表单组 id 为 29）

POST /field（插入 'Zip' 表单组 id 为 29）

...

但这看起来不对。提出了这么多要求。也许对每个新创建的公式/表单组/字段立即这样做是一种解决方案，而不是考虑立即保存整个数据结构。

第三种方法可能是拥有所有服务，但永远不要公开所有服务。将洞数据结构发送到 /formular 服务，该服务在内部调用其他服务 /formgroup 和 /field 以进行 CRUD 操作。但我不知道这是否仍然适用于钩子部分和羽毛续集功能。

实体关系模型：

实体关系模型

我的测试项目的源代码可以在这里找到：https ://github.com/Orbitkorbi/feathers-sequelize-test

关于应用程序的附加信息： 我的应用程序分为两部分。

  1. 运行 feathersjs 并为 REST API 提供其服务的服务器应用程序。
  2. 在浏览器中运行的客户端 SPA 调用 API

问题： 在feathersJS 服务、钩子、sequelize 关系和 RESTful API 方面如何做到这一点？

4

1 回答 1

1

您正在使用“服务”，大多数人会根据上下文使用“资源”、“端点”或（更一般地）“模块”。 关于“服务”的答案不太可能对您有所帮助。

第三种方法可能是拥有所有服务，但永远不要公开所有服务。将洞数据结构发送到 /formular 服务，该服务在内部调用其他服务 /formgroup 和 /field 以进行 CRUD 操作。

这种方法与 REST 最为一致。

中心思想是您的“REST API”是使您的应用程序看起来像一个通用文档存储（又名网站）的外观。想要向您发送信息的远程客户端通过建议对您网站上的资源进行编辑来实现。

您网站上的每个文档都独立于其他文档，并且可以使用所有文档共有的自我描述消息来提议对该文档的编辑。

所以

PUT /formular

向服务器建议它使其副本/formular看起来像客户端的副本是一种完全合理的方式。

然后，服务器负责 (a) 确定它想要如何更改其资源副本以响应请求，以及 (b) 弄清楚如何进行这些更改。

因此，如果 /formular 是从多个表中的多行构建的资源，则服务器将需要自行确定需要哪些数据库语句来适当地更新这些表。

这种复杂性被故意隐藏在 REST 外观背后——就客户端而言，您只是将资源的新表示形式写入某个文件中。

就单一职责原则而言，请求处理程序有一个职责——处理请求。您可能希望通过让请求处理程序将部分或全部工作委托给更简单的事情来实现这一点。

（例如解析HTTP请求、生成HTTP响应等）

于 2020-09-27T13:16:12.257 回答