哪个是保持逻辑角度的最佳位置？

Question

我正在开发一个角度应用程序。假设当我们实现某个按钮的 onclick 等功能时，调用 api，处理数据，在表中显示结果。表数据应该跨页面保留（因此我们需要保持变量处于服务状态）。

为了实现，首先我们可以开始从模板调用函数，然后在组件中我们可以做一些检查，并调用服务来获取数据。一旦我们得到了数据，如果我们想要处理数据，那么处理数据的函数应该在组件或服务中？

我们可以在服务文件中编写逻辑吗？或者它应该在组件文件中？最佳做法是什么？

方法一：

 getApi() {
    this.http
      .get(url)
      .subscribe(response=> {
          this.afterFetchingProcessData(response); // this might be some function in service file
      },error=>{
          // handle error
      });
  }

  afterFetchingProcessData(response){
       //process the data and assign to variable 
       this.tabledata = response;
  }

或者我们应该遵循以下模式

方法2：在组件文件中：

 getApi() {
      this.service.getApi().subscribe(response=> {
          this.afterFetchingProcessData(response); // this might be some function in service file
      },error=>{
          // handle error
      });
  }

  afterFetchingProcessData(response){
       //process the data and assign to variable 
       this.service.tabledata = response;
  }

在服务文件中只需调用 Api 并返回响应

 getApi() {
    return this.http
      .get(url);
  }

遵循方法 1 或方法 2 哪一个是最佳实践？为什么？

Answer 1

IMO 中，方法 2 是更好的选择。

我的看法是——

• 组件- 包括表示层，并且应该专注于向用户呈现并从他那里获取输入
• 服务——做所有其他事情

我会更进一步将服务分为：

• Side Effects Services - 负责 API 调用等
• 主要服务- 封装应用程序的行为

Answer 2

服务是一个广泛的类别，涵盖应用程序所需的任何价值、功能或特性。服务通常是一个具有狭窄、明确定义目的的类。它应该做一些具体的事情并且做得很好。

\n\n

Angular 将组件与服务区分开来，以提高模块化性和可重用性。通过将组件的视图相关功能与其他类型的处理分开，您可以使组件类精简且高效。

\n\n

理想情况下，组件的工作就是提供用户体验，仅此而已。组件应该提供数据绑定的属性和方法，以便在视图（由模板呈现）和应用程序逻辑（通常包括模型的一些概念）之间进行协调。

\n\n

组件可以将某些任务委托给服务，例如从服务器获取数据、验证用户输入或直接记录到控制台。通过在可注入服务类中定义此类处理任务，您可以使这些任务可供任何组件使用。您还可以根据不同情况注入不同的同类服务提供商，使您的应用程序更具适应性。

\n\n

Angular 并不强制执行这些原则。Angular 确实可以帮助您遵循这些原则，让您可以轻松地将应用程序逻辑纳入服务中，并通过依赖项注入使这些服务可供组件使用。

\n\n

组件控制一块称为视图的屏幕。例如，各个组件定义并控制教程中的以下每个视图：

\n\n

带有导航链接的应用程序根目录。\n英雄列表。\n英雄编辑器。\n您定义组件的应用程序逻辑\xe2\x80\x94它如何支持类内的视图\xe2\x80\x94。该类通过属性和方法的 API 与视图交互。

\n\n

\n

检查Angular文档中的架构

\n

\n