Question

这可能是基于意见的标记。但我正在寻找标准/最佳实践。我正在构建一个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

简单，通用的转换每个人都需要（例如data => data.user.firstName + ' ' + data.user.lastName）应该进入服务。

依赖于表示逻辑的视图特定转换（例如{{1}}）应该放在组件中。

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

Answer 2

从n层架构的角度考虑角度应用。尊重DRY原则和至少一些SOLID点 - 在这种情况下是服务中的S.将“组件”视为视图 - 演示者对（模型位于其他位置），而不是ASP.NET的webForms（标记与后面的代码相结合）。

有两种基本可能会影响您的设计细节 - 您的服务服务器端点是否了解您的视图模型。有些团队采用这种方法，在角度应用程序中需要很少的转换，因为服务器端模型非常接近角度视图模型。在这些情况下，任何非视图特定的内容都可以在您的服务中，并且组件中的视图特定转换正常。

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

Answer 3

您可以在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中的服务是否应该包含数据操作逻辑或组件？

3 个答案: