共享服务是否正确地在角度2中实现DRY？

Question

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

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

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

我看过共享服务，看起来非常有前景。 总之，我正在寻找角度正确的模块化结构，它以某种方式帮助我转换旧的HMVC codeigniter模块结构。

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

Answer 1

我强烈建议您按照Angular.io样式指南来构建Angular应用程序。这些指南通过将LIFT原则一致地应用于组织代码的传统方法（例如将相关组件分组到单独的文件夹（即具有模型层，服务层等））而有利于简化。这将允许您的应用程序随着时间的推移而扩展，从一个非常简单的应用程序（少于十个文件）演变为功能更全面的复杂应用程序（包含数百甚至数千个文件）。

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

亮点：

1. 在决定文件夹结构或文件位置时，始终遵循LIFT原则。
2. 遵循按功能分组的原则（每个文件夹代表应用程序域中的一个功能，每个功能都有一个模块，用于打包组件，指令，管道和服务）。
3. 从功能文件夹中利用桶（即重新导出模块，服务，模型等的index.ts）。这将有助于保持模块模块化，并在以后需要时更容易将模块分离到自己发布的包中。
4. 拥有一个旨在由AppModule导入的Core模块，其目的可能包括使用根注入器注册应用程序范围的服务。利用forRoot和forChild约定来确保服务靠近使用它们的模块（LIFT），同时仍允许它们注册为应用程序范围的单例。
5. 有一个或多个共享模块，用于由功能模块导入。其目的是公开可在整个应用程序中重用的组件，指令和管道。避免在共享模块中使用单例服务（有意的单例是好的）。
6. 要注意深层嵌套的导入语句 - 这是一种明显的代码味道，并且表明您可能违反了LIFT原则。将代码重新分解为第1-5步。
7. 避免将所有模型放在一个文件夹中，将所有服务放在另一个文件夹中等。这违反了LIFT，使得查找与特定功能相关的代码变得更加困难，并且难以在将来将代码分离为可重复使用的软件包。 / LI>

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

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