在环回 4 中创建 requestBody 的最佳实践是什么？答案

【问题标题】：What is the best practice of creating requestBody in loopback 4?在环回 4 中创建 requestBody 的最佳实践是什么？
【发布时间】：2021-04-02 21:10:46
【问题描述】：

目前我正在研究 Loopback4，我遇到了这个问题。

    @requestBody({
      content: {
        'application/json': {
          schema: getModelSchemaRef(LoginCredentials, {
            title: 'Login'
          })
        },
      }
    }) credentials: LoginCredentials

在这个代码块中，我为请求正文创建了一个模型。这是定义请求正文的最佳方式吗？

【问题讨论】：

标签： javascript node.js typescript loopbackjs loopback4

【解决方案1】：

这是定义请求正文的最佳方式吗？

是的。模型的主要目的是成为定义任何数据形状的主要接口。这使得跨不同层（例如 REST 和存储库）的重用成为可能，并鼓励创建单一的事实来源。这意味着更好的长期代码可维护性，例如数据设计漂移和重复代码等问题。

还有其他方法可以定义请求正文吗？

是的。请求正文装饰 (@requestBody()) 接受 OpenAPI 3.0 规范对象。因此，可以编写 OpenAPI 规范，而不是依赖 getModelSchemaRef() 从模型生成它。但是，应谨慎执行以缓解上述问题。

如果我的模型太多怎么办？

启动的工件可以存储在嵌套目录中；因此，模型可以按其业务领域进行隔离。例如，与身份验证相关的模型可以存储在src/models/auth/MyModel.model.ts 下。

模型之外的代码隔离

另一种解决方案是使用组件分离代码。如果做得好，组件可以通过从主代码库中隐藏引导逻辑和工件来实现近乎完全的代码分离。例如，所有身份验证代码和工件 - 尽管有控制器、数据源和模型 - 都可以保存在 src/components/auth/* 下。从应用程序的其余部分的角度来看，唯一需要的操作是使用app.component(MyAuthComponent) 绑定组件，也许还有一些绑定配置。这意味着有明确的职责分离，从而提高了代码的可读性，因为除非必要，否则开发人员不必查看隔离代码的实现细节。

【讨论】：