共享服务在角度 2 中实现 DRY 的正确方法吗?

Question

我正在寻找在角度2中实现ERP前端。我在代码点火器 HMVC 结构中拥有我的现有实现。我已经将所有模型/控制器调用转换为 REST APIS。

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

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

我看过共享服务，它看起来很有前途。 简而言之，我正在寻找正确的角度模块化结构，这以某种方式帮助我转换旧的HMVC点火器模块结构。

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

Answer 1

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

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

突出：

1. 在决定文件夹结构或文件位置时，始终遵循 LIFT 原则。
2. 遵循按功能文件夹原则(每个文件夹表示应用程序域中的一个功能，每个功能都有一个打包组件、指令、管道和服务的模块)。
3. 利用从功能文件夹中重新导出模块、服务、模型等的桶(即重新导出模块、服务、模型等的索引)。 这将有助于保持模块的模块化，并且以后如果需要，可以更轻松地将模块分离到其自己的已发布包中。
4. 有一个核心模块，旨在由 AppModule 导入，其用途可能包括向根注入器注册应用范围的服务。 利用forRoot和forChild约定来确保服务靠近使用它们的模块 (LIFT)，同时仍允许将它们注册为应用范围的单一实例。
5. 具有一个或多个共享模块，旨在由功能模块导入。其目的是公开可在整个应用程序中重用的组件、指令和管道。避免共享模块中的单一实例服务(有意的单一实例是可以的)。
6. 请注意深度嵌套的导入语句 - 这是一个明显的代码气味，表明您可能违反了 LIFT 原则。 重构代码以遵循第 #1-5 点。
7. 避免将所有模型放在一个文件夹中，将所有服务放在另一个文件夹中等。 这违反了 LIFT，使得查找与特定功能相关的代码变得更加困难，并且将来将代码分离到可重用的包中具有挑战性。

下面是一个兼容的示例文件夹结构：

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