Angular 了解@NgModule的用法

这个新的@NgModule垃圾把我难住了。在此之前，我能够通过

@Component

元对象的

指令：[]

属性清晰地指定

@Component

的指令依赖项。因此：

@Component({ /* ... */ })
export class Cmp1 {}

@Component({ /* ... */ })
export class Cmp2 {}

@Component({
  /* ... */
  directives: [Cmp1]
})
export class Cmp3 {}

@Component({
  /* ... */
  directives: [Cmp2, Cmp3]
})
export class Cmp4 {}

现在，在“方便”的幌子下，我必须声明一个@NgModule，在一个数组中包含这四个组件，如下所示：

@NgModule({
  declarations: [Cmp1, Cmp2, Cmp3, Cmp4],
  exports: [Cmp4],
  imports: [Cmp1, Cmp2, Cmp3, Cmp4]
})
export class YetAnotherWrapperClass {}

这难道不会掩盖我的组件的真正依赖关系图吗？如果我这样做，我怎么知道实际上是Cmp3依赖于Cmp1？哦，当然，我可以在这里或那里省略一些导入语句，但似乎代价是失去每个组件的显式依赖关系

---

我通读了《迁移指南》和《角度模块指南》，但我觉得我根本不同意@NgModule的设计决策。我遗漏了什么吗？

引入

@NgModule（）

的目的是允许路由器延迟加载，而不是引入另一种声明组件依赖关系的方法。这只是一个副作用

诚然，对于组件或指令，您不再获得清晰的依赖关系图，但是如果您将应用程序拆分为每个

NgModule

的功能，您将获得清晰的功能依赖关系图，这一点更有意义

导入仅适用于

NgModule

s，不适用于组件或指令。 因此，该行无效

导入：[Cmp1、Cmp2、Cmp3、Cmp4]

应该是这样的

---

导入：[Feature1模块，Feature2模块]

事实上，它模糊了。这就是为什么我们可以有嵌套的模块！如果您已经处理过A1，那么您应该熟悉该模式。这是一个很好的老式

角形模块

，只是更令人毛骨悚然。哈！这正是我所担心的。感谢您对导入和以功能为中心的设计理念的澄清，Günter。我当然可以欣赏AoT和延迟加载的好处。我希望ng2能够解决ng1的名称冲突问题，例如，不能在同一项目中使用相同名称的服务或指令。我认为这是一个小小的改进：不同的特性封装了它们自己的依赖项，不需要担心命名冲突。只有在将具有相同选择器的两个选择器导入到一个模块（使用该选择器的模块）中时，指令选择器、组件选择器和管道选择器才会发生命名冲突。否则TS导入就足以区分两个同名的类。再次感谢您的快速跟进。顺便说一句，如果我的挫败感被说成是吃力不讨好，我向你道歉。有时候我忘了互联网不是一个大地方。你们的工作做得很好，为像我这样的开发人员提供了更快完成工作的工具，继续努力@我没有感觉到任何挫折。你发表评论是因为你读了我对几分钟前提出的另一个问题的评论吗？我理解当人们讨论他们是否喜欢或不喜欢某个“功能”时，所提到的问题是关于一个快速发展的项目的文档不是100%准确，而是尽可能清楚地说明实际问题的10行。这只是在浪费每个人的时间，他们必须先读一遍，然后才能得出真正的问题。我也不是谷歌。哈哈，不，实际上我不知道你提到的问题。奇怪的我发誓我曾在angular2撰稿人名单上看到过你，但现在我发现情况并非如此。请忽略我之前的评论（尽管我相信你做得很好，至少回答了一些问题）。我同意你的观点，对于一个快速发展的早期项目，抱怨文档是徒劳的。。。这与领土有关。