我们有一个中等大小的Angular 4应用程序（+ -150个组件）。
其中许多组件需要注入服务类，并且需要在应用程序中声明其他组件。
我们一直在尝试的方法，并且发现更加开发人员友好，是为每个组件创建一个模块。该模块导入子组件模块并提供（或导入）组件所需的所有服务。它还导出组件本身，以便其他组件可以通过模块引用它。
它使组件的组成变得轻而易举，并且组件的测试夹具的设置非常简单（这是以前很多重复依赖项和子组件树依赖项的地方）。 这种方法似乎与基于组件的体系结构相匹配，并允许围绕组件依赖性的封装形式 感觉真好太棒了;）
我的问题是，拥有这么多模块会对性能（或其他）产生什么影响？
答案 0 :(得分：17)
我认为每个组件一个模块是设计Angular应用的最佳方式。
如果它依赖于其他组件，则只能包含与直接依赖的每个组件相关的组件模块，并且不需要关心间接依赖关系
一开始可能看起来更有用，但它会让你回来减少维护问题。
如果ComponentA取决于依赖于ComponentB的{{1}}，请创建一个：
ComponentC 相关的 ModuleC
与导出ComponentC
ModuleB相关的 ComponentB
与导出ModuleC的{{1}}相关的
ModuleA（不需要直接导入ComponentA）
如果ModuleB现在取决于ModuleC（例如在模板中包含ComponentB），并根据ComponentD停止，则只需更改<my-component-d>以及所有组件即可如果你使用这种方法，取决于ComponentC将正常工作。
现在想想数以百计的组件。有多少组件取决于ModuleB？
我认为这个问题类似于在脚本标记中包含js文件的旧方式（或不太旧）：
ComponentB如果您根据ComponentB更改<script src="build/a.js"></script>
<script src="build/b.js"></script>
<script src="build/c.js"></script>
停止并根据b启动，则导入c的所有网页现在都必须导入d，等等，导致维护噩梦。您可能还忘记删除（现在不需要的）b并在某些页面中不必要地导入它，增加启动时间（或更糟，将其从导入的所有文件中删除{{1}但是，某些页面导入d取决于c.js并且您破坏了该页面的某些功能。）
相反，我认为导入更好：
b.js或
e.js并且依赖关系由模块捆绑器处理，如c.js。
有一种方法可以制作一个包含大量组件的模块并导入它，但最终导入了几个你不使用的组件，如果你使用延迟加载，您的模块可能会变得很大，除非您在AppModule中导入该模块，使启动时间增加。
您仍然可以使用每个模块一个组件的方法与功能模块。只需将组件模块导入功能模块（而不是组件本身）：
feature.module.ts：
<script src="build/bundle.js"></script>
（您可能也想要导出它们。）
我还认为这种方法是创建库时的最佳方法，否则你会强制库的消费者导入所有组件，即使他们只使用1或库中的2个组件。
我遇到<script src="build/vendor.js"></script>
<script src="build/main.js"></script>
这个问题：缩小的webpack库有imports: [
ComponentAModule,
ComponentBModule,
ComponentCModule,
]
，其中ionic3是组件（希望它会随{{1}而变化}）。我只使用了几个ionic-angular组件，没有必要导入所有这些组件，但是我没有选择（除非我分叉回购或停止使用它）。
我有一个包含176个组件的应用程序，这是我认为最好的方法。以前，我在功能模块中包含了几个组件，后来给我带来了一些麻烦。此外，将组件从功能模块更改为另一个组件时更难（它的依赖关系怎么样？它们全部混合在一起）。
我没有找到令人满意的服务方法（437KB）。
最终由你决定。根据我的经验，这是我的意见。