Angular：每个组件一个模块：反模式？

Question

所以我遇到了一种做法，人们会为每个具有服务依赖关系的组件创建一个模块。这样，当有人想要使用给定的组件时，他们不必通读代码来查看要添加到给定模块的提供程序。这是反模式吗？它会导致性能问题还是什么？

对于给定模块中应该有多少个组件/指令/提供者/等，是否有一些关于下/上限的推荐指南？是否对 angular/angularJs 生态系统进行了测试，其中包含 100 个模块？相比之下，如果只是常规组件都捆绑在 20 左右的模块中呢？

Answer 1

通常，Angular 中有不同的模块类型，以及关于它们应该包含什么以及应该导入哪些模块的指导：

• 小部件模块 - 主要包含 UI 组件，但不包含服务。由功能模块导入。
• 功能模块 - 包含特定于域的私有组件。由 AppModule 导入。
• 服务模块 - 专门包含服务。由 AppModule 导入。
• 路由模块 - 一个专门的功能模块，它是路由的目标。
• 路由模块 - 包含导航路线和解析器/防护服务。

模块可以依赖于其他模块。例如，一个 Widgets 模块应该与一个 Services 模块一起使用，其中 AppModule 导入 ServicesModule，而 FeatureModule 导入 WidgetsModule。BrowserModule/CommonModule 就是这种模式的一个例子；RouterModule.forRoot()/RouterModule.forChild() 也是如此。

我会说每个组件有一个模块是多余的。很难将通用功能组织和分组在一起，并以任何有意义的方式利用服务。当单个模块的导入达到两位数时，它很容易变得笨拙。

[编辑]

重新阅读这个问题后，我想补充一点，因为我认为 NgModule 封装的单组件方法值得更多关注。我不相信 1:1 的模块到组件——那太过分了。但是，我完全支持 1:many module-to-component，其中模块仅导出一个组件，而所有其他组件都是该模块私有的。后一种方法称为 NgModule 封装，它是一种以松散耦合顶级组件的方式构建应用程序的极好方法。