angular - 共享服务是在 Angular 2 中实现 DRY 的正确方法吗？

Question

我正在寻找以 Angular 2 实现 ERP 前端。我在 codeigniter HMVC 结构中有我现有的实现。从中我已将所有模型/ Controller 调用转换为 REST APIS。

较旧的结构是在 CRM、会计、交易等模块中重用大量 View 组件进行 CRUD 操作。

我怀疑是否有任何方法可以通过更多优化在 Angular 4 中实现相同的模式。

我看过共享服务，它看起来很有希望。
简而言之，我正在寻找正确的 Angular 模块化结构，它以某种方式帮助我转换旧的 HMVC codeigniter 模块结构。

如果您需要更多关于新旧结构的实现。让我知道。

Answer 1

我强烈建议遵循 Angular.io 风格指南来构建 Angular 应用程序。这些指南通过一致地应用 LIFT 原则而不是组织代码的传统方法(例如将相关组件分组到单独的文件夹(即具有模型层、服务层等))来支持简​​单性。这将允许您的应用程序随着时间的推移而扩展，因为它从一个只有不到十个文件的非常简单的应用程序演变为拥有数百甚至数千个文件的功能更全面的复杂应用程序。

https://angular.io/guide/styleguide#application-structure-and-ngmodules

强调:

在决定文件夹结构或文件位置时，始终遵循 LIFT 原则。

遵循 Folders-by-Feature 原则(每个文件夹代表应用程序域中的一个功能，每个功能都有一个模块，用于封装组件、指令、管道和服务)。

利用功能文件夹中的桶(即重新导出模块、服务、模型等的 index.ts)。这将有助于保持模块的模块化，并且如果需要，以后更容易将模块分离到自己发布的包中。

有一个核心模块，旨在由 AppModule 导入，其目的可能包括向根注入(inject)器注册应用程序范围的服务。利用 forRoot和 forChild约定以确保服务靠近使用它们的模块 (LIFT)，同时仍允许将它们注册为应用程序范围的单例。

有一个或多个共享模块，旨在由功能模块导入。其目的是公开可在整个应用程序中重用的组件、指令和管道。避免共享模块中的单例服务(有意的单例是可以的)。

注意深度嵌套的 import 语句——这是一种明显的代码异味，表明您可能违反了 LIFT 原则。重构您的代码以遵循第 1-5 点。

避免将所有模型放在一个文件夹中，将所有服务放在另一个文件夹中，等等。这违反了 LIFT 并使得定位与特定功能相关的代码变得更加困难，并且在将来将代码分离到可重用的包中具有挑战性。

这是一个兼容的示例文件夹结构:

https://angular.io/guide/styleguide#overall-structural-guidelines