【问题标题】:Should i use new services for each table in my db.json?我应该为 db.json 中的每个表使用新服务吗?
【发布时间】:2019-03-23 14:01:13
【问题描述】:

我不确定是否应该为数据库中的每个表使用单独的服务(获取或/和删除数据)。还是可以将它们保留在一项服务中?我认为无论哪种方式都可以,我对 Angular 有点陌生,所以只是要求一个正确的答案。

db.json:

{
  "products": [
    {
      "id": 1,
      "name": "Product1",
      "description": "fdfdf",
      "price": 10.20
    },
    {
      "id": 2,
      "name": "Product2",
      "description": "fdfdf",
      "price": 20.00
    },
    {
      "id": 3,
      "name": "Product3",
      "description": "fdfdf",
      "price": 30.00
    },
    {
      "id": 4,
      "name": "Product4",
      "description": "fdfdf",
      "price": 40.00
    }
  ],
  "brands": [
    {
      "name": "brand1",
      "country": "country1"
    },
    {
      "name": "brand2",
      "country": "country2"
    },
    {
      "name": "brand3",
      "country": "country3"
    }
  ]
}

my service: 

export class ProductService {
  private url: string;
  constructor(private http: HttpClient) {
    this.url = 'http://localhost:3000';
  }

  public getJsonProducts(): Observable<any> {
    return this.http.get(this.url + '/products');
  }
  public getJsonBrands(): Observable<any> {
    return this.http.get(this.url + '/brands');
  }
}

【问题讨论】:

  • 最佳实践是每个资源一个服务。服务应该小而专注。通常,一种基本服务会成为许多服务的基础,例如某种 http 助手。在一个非常简单的应用程序中将所有资源保存在一个服务中可能很好,但任何远程复杂的东西都会变得混乱和难以管理。但是,这是一个意见问题,而不是特定的编程问题,不适合 SO
  • 您的数据库是否只有两个表?如果是这样,那也没关系。它有100个吗?如果是这样,您是否愿意接受一个包含数百种不同方法并且每个开发人员每次需要更改或添加某些内容时都必须修改的类?

标签: angular


【解决方案1】:

这有点取决于您调用的服务。如果每个表的大体结构相同,并且可以控制调用哪个端点,从服务中的方法传递哪些参数,比如

// inside my service
getTableData(endpoint: string, params: paramInterface) {
    return this.http.post(`api/getTableData/${endpoint}`, { params }, { headers });
}

那就完全没问题了,值得鼓励!因为您避免重复代码(DRY 原则)。

另一方面,如果每个表有不同的请求,那么你应该让每个组件都有它的服务。

不过,我的方法是创建一个抽象表服务,它在构造时获取参数,然后使用这些参数进行调用,并在从该基本抽象表服务扩展的每个组件中创建一个服务,这样你就不用了t 重复代码(DRY),但也可以实现任何服务之外的任何东西,并且每个服务都做自己的事情(职责分离)。

希望我的答案能启发我,而不是让更多人感到困惑!

【讨论】:

    猜你喜欢
    • 2017-09-15
    • 2022-08-11
    • 2023-04-05
    • 2021-10-18
    • 1970-01-01
    • 2011-02-23
    • 1970-01-01
    • 1970-01-01
    • 2018-03-21
    相关资源
    最近更新 更多