最佳实践：Loopback 中的服务层

Question

我正在环回中构建应用程序，想知道如何使用与任何模型无关的 API 构建服务层。这是我的场景。

我有两个型号User、Game、UserGames。 UserGames 是一个many-to-many 关系，存储用户在不同游戏中的得分。我想为weeklyLeaderboard 提供一个API，但我不希望它成为我的任何模型的Remote Method，因为它不符合RESTful API 准则。

我现在能找到实现的唯一方法是在访问该服务的server/boot/routes.js 中创建一个服务common/service/weeklyLeaderboard.js 和一个route。在这种情况下，我将不得不重新安排我的middleware.json 中的中间件，以便以与远程方法相同的方式处理非远程方法端点并可以访问 currentContext。

有没有更好的方法来实现与特定模型无关但访问多个数据访问和业务对象的 API。

Answer 1

免责声明：我是 LoopBack 的合著者和积极维护者。

在我们最近发布的 LoopBack 版本 4 中，我们将 REST API 与数据库访问分离。 REST API 由Controller 类实现，数据结构由Models 描述，数据库通过Repositories 访问。这使得编写与数据访问细节分离的服务层变得容易。

在 LoopBack 3 中，我建议创建一个新模型（例如Leaderboard）并将其视为控制器。要让它发挥作用需要两个技巧：

• 从Model 继承，而不是默认的PersistedModel。这样，您的类控制器模型开始为空，没有（内置）远程方法。
• 不要将类似控制器的模型附加到任何数据源。在server/model-config.json 中，将新模型的dataSource 条目设置为null。

然后您可以将您的 weeklyLeaderboard 端点定义为常规 remote method 并获得 LoopBack 提供的所有好处，例如您的新端点将包含在生成的 Swagger 规范中，并可通过 API Explorer 进行测试。