在 REST API 控制器中什么时候适合对资源使用单个服务还是多个服务？

Question

我有一个 REST 端点 GET /products，它响应一系列产品。 底层服务

getProducts

对第三方API进行提取调用，然后转换产品以符合我们带有附加字段的数据结构。

是否最好将服务分成两个服务，一个仅获取产品，另一个用于转换产品，并让控制器按顺序调用每个服务：

const getProductsController = async (req, res) => {
  try {
    const products = await ProductService.getProducts();
    const transformedProducts = ProductService.transformProducts(products);
    res.status(200).json(products);
  }
}

或

将单个服务中的获取和转换与每个服务的实用函数结合起来是否更好？

const getProductsController = async (req, res) => {
  try {
    const products = await ProductService.getProducts();
    res.status(200).json(products);
  }
}

Answer 1

两种方法都有其优点，最佳选择取决于以下几个因素：

单一服务：

优点：

更简单的代码：编写和维护的代码更少，特别是在转换很简单的情况下。 改进的性能：将获取和转换结合在单个调用中可能会稍微快一些（尽管对于大多数应用程序来说可以忽略不计）。 封装：处理产品的逻辑包含在一个地方，更容易理解和修改。 缺点：

不太精细的控制：您无法轻松地单独重用获取或转换逻辑。 测试复杂性：测试服务变得更加复杂，因为它包括外部 API 调用和内部逻辑。 紧密耦合的潜力：如果第三方 API 发生变化，可能需要修改获取和转换逻辑。 多项服务：

优点：

松耦合：第三方API的改变只影响抓取服务，不影响转换。 可重用性：您可以轻松地将获取服务重用于其他目的。 可测试性：每个服务都可以独立测试，更容易隔离和修复错误。 关注点分离：代码更加有条理，遵循单一职责的原则。 缺点：

更多代码：您需要为多个服务编写和维护更多代码。 可能更慢：额外的服务调用可能会带来轻微的性能开销。 复杂性增加：管理多个服务会增加整体架构的复杂性。 根据您的具体情况：

如果转换很简单并且不太可能改变，那么单个服务可能就足够了。 如果转换很复杂或者可能需要独立修改或重用，请考虑将其拆分为单独的服务。 如果您计划使用需要从不同来源获取或转换数据的其他功能来扩展 API，则多个服务可提供更大的灵活性和可重用性。 最终，最佳选择取决于您的具体需求、开发偏好以及 API 的未来计划。在做出决定时，请考虑简单性、可维护性、可重用性和可测试性之间的权衡。