Angular 功能模块与共享模块答案

【问题标题】：Angular feature module vs shared moduleAngular 功能模块与共享模块
【发布时间】：2020-05-03 07:59:09
【问题描述】：

假设我有一个功能模块 person 和一个功能模块 cars。现在我想显示一个包含所有人的表格。单击表格行时，表格应展开，显示包含一个人的所有汽车的汽车表格。现在，当单击汽车行时，我希望汽车表展开显示所有拥有此类汽车的人。

|姓名 |年龄 | |彼得 | 25 | | > 汽车 |品牌 |型号 | | |丰田 |卡罗拉 | | | > 人员 |姓名 |年龄 | | | |彼得 | 25 | | | |弗雷德 | 35 | |汉斯 | 28 | |弗雷德 | 35 |

因此我有一个循环依赖，因为 person-table -> car-table -> person-table 来自两个不同的功能模块。是否可以考虑将 person-table 和 car-table 移动到 SharedModule 以填充用例？

【问题讨论】：

【解决方案1】：

我更喜欢遵循 每个模块一个组件 设计模式，并使用 惰性模块 来实现具有单个 main 模块引导一切的功能。

main 模块应该具有启动应用程序所需的最少依赖项，因为这可以提高加载性能，并且 top level 路由应该是延迟加载的。因此，当应用程序启动时，延迟加载的第一个功能是 main 应用程序。所有其他惰性模块都是子路由。

惰性模块应该只具有该功能所需的出口组件和服务（提供者）。所有其他 visual 组件都来自一个 shared 文件夹，该文件夹包含 每个模块一个组件 目录。

此设计模式确实遵循设计指南，但具有更细粒度的模块。它确实创建了更多样板代码和更多文件，但同时具有可维护性优势和编译时间优势（即摇树更有效）。

对我来说典型的项目结构：

src/app
+-- lazy
+-- main
+-- shared

一个典型的惰性模块应该是这样的结构

src/app/lazy/feature
+-- OutletFeature
+-- feature.module.ts
+-- feature-routing.module.ts

惰性特性将包含守卫、解析器和服务。你也可以添加额外的组件，如果它们是 unique 到该功能，但我尽量将其保持在最低限度，因为通常它们最终会在类似的功能稍后添加。

shared 文件夹包含组件。

src/app/shared/Example
+-- Example/example.component.ts
+-- example.module.ts

上面是一个带有同名模块的示例组件。遵循组件目录模式，同名文件夹包含组件。共享模块不限制到单个组件，但是组件的消费者应该只期望看到一个组件由模块导出。在表格的示例中，共享组件将是一个表格，但模块可能包含用于页眉、行和页脚的内部组件。这个想法是该模块只有一个目的。

以上所有内容均为意见，风格指南为小型项目提供了很好的模式。我在几个大型应用程序中使用过上面的，感觉它的扩展性很好。

Angular Material 库使用 每个模块一个组件 模式作为示例。他们有一个自定义的构建过程，一开始他们的源代码结构有点混乱，但是一旦你进入组件部分，一切都是一个单独的组件。

【讨论】：

感谢分享。这是一种非常有趣的方法，我一定会试一试。尽管如此，我还是会保留这个问题，以便就此获得更多意见。
在考虑了您的方法一段时间后，我认为这不会解决我的问题。即使我的每个表都有一个模块，我也会有一个循环依赖，比如 person-table-module -> car-table-module -> person-table-module