时间戳

首页 > 解决方案 > 哪个是保持逻辑角度的最佳位置？

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

问题描述

我正在开发一个角度应用程序。比方说，当我们实现一个功能时，比如点击某个按钮，调用一个 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 的最佳实践是什么？为什么？

标签： angular

解决方案

对于除了原型和简单或短暂的应用程序之外的任何东西，除了最简单的业务逻辑之外的任何东西都应该被提取到基于类的服务或其他依赖项中。至少，组件应该分为表现组件和容器组件或类似的模式。

我将引用我自己的文章“精益 Angular 组件”。

简而言之，精益 Angular 组件对于简单的应用程序或生命周期较短的项目，混合组件是可以接受的，因为对代码库的可维护性、可扩展性甚至可测试性的需求不大。

对于大型、复杂的应用程序，我们更需要最大化刚才提到的有价值的特征。为此，我们需要只包含属于展示的水平应用层的逻辑的展示组件。这些组件应该只处理单个抽象级别的问题。

精益展示组件只关心向我们的用户展示信息并允许他们与应用程序交互。实现细节留给属于不同水平应用层的其他软件工件。演示或用户交互的复杂逻辑被委托给组件级服务，例如演示者。

我们还可以拥有精益容器组件。他们将应用程序状态投射到表示组件，并将特定于应用程序的事件转换为影响应用程序状态的命令。复杂的逻辑被委托给组件级服务，例如外观——甚至可能是特定于组件的服务。

正如本文所讨论的，使组件模型精简和精简对应于 Angular 样式指南中的几个建议。

那么共享状态应该放在哪里呢？以下是一些选项：

  • 具有 RxJS 主题的基于类的服务
  • 组件树中较高的页面/容器组件
  • 状态容器或状态管理框架/库中的其他选项，例如 RxAngular State、Elf、NgRx Store、NgRx Effects、NgRx Component Store、Akita、NGXS、Redux-Observable、MobX 或 NGXF

推荐阅读