Angular 2 中的服务应该包含数据操作逻辑还是组件？

Question

这可以根据意见进行标记。但我正在寻找 standard/best-practise。我正在构建一个 Angular 2 应用程序，我必须先处理 API 中的数据，然后才能在模板中显示它。例如，如果我的服务如下所示：

getData(id: number): Observable<Data> {
    return this.http
      .get(this.url + '/' + id)
      .map((res) => {
        return res.json().data;
       });
  }

  prepareData(data) {
    // manipulate and return the data
  }

在我的组件上，我可以这样调用服务：

getData(id: number): void {
    this.dataService.getData(id)
      .subscribe((data: Data) => {
        this.showData = this.dataService.prepareData(data)
      };
  }

但这是标准方法吗？还是应该将 prepareData 函数包含在组件中？

另一种表述方式是，与组件相比，服务应该重一些还是应该轻一些，仅作为获取数据的接口？

Answer 1

简单、通用的转换每个人都需要（例如res => res.json().data）应该加入服务。

依赖于表示逻辑（例如 data => data.user.firstName + ' ' + data.user.lastName）的特定于视图的转换应该放在您的组件中。

服务应该能够提供数据而不知道将呈现什么。组件应该能够呈现数据 而不知道数据来自哪里 .

Answer 2

从 n 层架构的角度考虑您的 angular 应用程序。尊重 DRY 原则和至少一些 SOLID 点 - 在这种情况下是您服务中的 S。将 "Components" 视为视图-呈现器对（模型在其他地方），而不是 ASP.NET 的 webForms（标记加上隐藏代码）。

有两种基本的可能性会影响您的设计细节——您的服务服务器端点是否知道您的视图模型。有些团队采用这种方法，您的 angular 应用程序几乎不需要转换，因为服务器端模型与非常接近 angular 视图模型。在这些情况下，任何非视图特定的内容都可以在您的服务中使用，组件中视图特定的转换也可以。

另一方面，如果您需要将更通用的 service/server 响应映射到您的 angular 视图模型，您不希望在服务中执行此操作。如果有可能在其他视图中重用此模型（将其视为业务 class，而不仅仅是 DTO），您也不想在组件中执行此操作。由于映射可能涉及业务规则，因此最好在 angular 应用程序中隔离专用模型和映射器层，并保持服务和组件 DRY 和 "S"。创建一个单独的 model/business 层也很好，因为它实际上可以帮助您以后轻松替换 UI 框架。

Answer 3

您可以操作 return getData() 中的数据。您可以编写如下代码-

getData(id: number): Observable<Data> {
    return this.http
      .get(this.url + '/' + id)
      .map((res) => {
          let data=  res.json().data;
          return this.prepareData(data);
       });
  }

  prepareData(data) {
    // manipulate and return the data
  }

如果您有具体情况可以简单描述一下，我希望这对您有所帮助，我会帮助您。

Angular 2 中的服务应该包含数据操作逻辑还是组件？

Should services in Angular 2 hold the data manipulation logic or the components?

javascript

angular

angular2-services