我应该在角度5或仅1个文件中使用多个服务文件来执行所有功能吗？

Question

我有多个API用于不同的组件，所以我更喜欢做什么，是将所有功能放在一个服务中还是应该创建多个服务。示例 - 组件1使用4个特定功能，总共10个功能。我应该为10个功能创建1个服务，还是两个不同的服务分别由4个和6个功能组成

Answer 1

要确定服务文件的Angular体系结构，您需要牢记以下几点：

• 模块（功能）特定文件应保存在单独的模块中。你的代码应具有高凝聚力
• 如果存在不同模块所需的公共服务文件，则创建共享模块并将所有common.svc.ts文件放入其中。原因是，您可以为所有模块重用该服务。
• 在shared模块中创建服务文件时，请尝试根据它们提供的功能进一步细分。这会将您的长服务文件分解为有意义的小文件，这些文件更易于维护。
• 您还可以创建一个本身没有任何业务逻辑的common.svc文件，而是提供对所有公共服务的访问。此common.svc的重要性在于您不必在shared内注入所有components服务。只需注入此shared文件，即可访问所有common.svc服务。它将充当访问所有shared服务的网关。现在，您只需在组件中注入 1 shared即可访问 5 common.svc服务。

如果您需要对上述任何一点进行更多说明，请与我们联系。

您可以推荐 SOLID设计主体以获得更好的代码，无论您的语言是什么

Answer 2

这完全取决于你的策略，你应该看到未来并思考所有的可能性。这是我的应用程序中的逻辑。

通常我会为每个模块使用一个特定的服务，例如，如果我们想拥有一所大学的网站

1. Student.module
2. Class.module

每个模块都有组件和一个服务，对于每个服务，我们将有四个一般操作

1. 添加
2. 修改
3. 删除
4. 列表

所以我将在以下地址中提供服务。

1. 应用/类/ class.service.ts
2. 应用/学生/ student.service.ts

另一个逻辑是在app-root中创建一个名为service的文件夹，并将所有服务放入其中。 （不推荐），其结构如下

1. 应用程序/服务/ class.service.ts
2. 应用程序/服务/ student.service.ts

最糟糕的逻辑是在app-root中创建一个名为service.ts的文件并粘贴其中的所有服务代码（从不推荐）

Answer 3

请参阅：Angular Style Guide by Angular.io

您应该遵循SOLID原则，对于您的案例，请遵循单一责任原则

你的课程应该针对单一的功能，即单一的责任，这表明你不应该混合你的所有代码，即在一个类别中的可重复性

示例：客户类处理客户相关活动，不应处理与用户相关的活动

如果你要添加所有不相关的方法，那么你就要对一个课程负责太多。为避免这种情况，您应该通过创建仅包含相关方法的类来分离责任。