Angular2:CoreModule与SharedModule

Question

有人可以解释什么是一个SharedModule和一个CoreModule代表什么？

我一直在观察几个使用这种方法的项目,以便建立它的角度项目.

1. 为什么我需要两个模块？
2. 我什么时候应该导入每一个？
3. 其中imports,exports,declarations应该每个人有吗？

Answer 1

TLDR:

1. CoreModule应该只有services和只导入一次AppModule.
2. SharedModule除了services并且需要共享内容(也可能是AppModule)的所有模块中都应该有任何东西.

但:

真实世界的模块通常是有意偏离[上述]指南的混合模块.这些准则不是法律; 除非你有充分的理由不这样做,否则请关注他们.

RTFM:

所以,经历了整个后NgModules'文档(加上一些其他的东西,了解情况),我很容易找到你的第二和第三个问题的回答 有.他们是:

SharedModule

• 创建一个SharedModule与components,directives和pipes你在你的应用程序中使用无处不在.该模块应完全由declarations其中大部分导出.
• 该SharedModule可再出口等微件模块,如CommonModule,FormsModule并与UI模块控制您使用最广泛.
• 本SharedModule不应该有providers原因前面解释.任何进口或再出口的模块都不应该有供应商.如果您偏离本指南,请了解您正在做什么以及为什么做.
• 导入SharedModule功能模块,包括应用程序启动时加载的功能模块和稍后延迟加载的功能模块.

CoreModule

• 为应用程序启动时加载的单例服务创建一个CoreModulewith providers.
• 仅CoreModule在根目录中导入AppModule.切勿导入CoreModule任何其他模块.
• 考虑制作CoreModule一个没有的纯服务模块declarations.

虽然这些比TLDR上面的版本更详细,你现在可以继续并继续编码,它提到了一些你必须阅读文档才能理解的东西(即'widget module',"之前解释的原因","纯服务模块" ),它也没有回答你的第一个问题.

所以我们试着这样做吧!

为什么我需要两个模块？

您不需要两个模块.这是文档中的内容:

在具有少量组件的简单应用程序中,您只需要根模块.

话虽如此,首先提出一个不同的问题很重要:

为什么人们将项目组织成多个模块？

对此的基本解释恰好在文档中的上述声明之后:

随着应用程序的增长,您将根模块重构为表示相关功能集合的要素模块.然后,将这些模块导入根模块.

但你问"为什么？" 这需要的不仅仅是基本的解释.因此,让我们开始解释如果您的应用程序开始增长并且您没有将功能分离到功能模块中可能会发生的问题:

• 根模块开始变得混乱,代码难以阅读和使用,因为它必须导入所有依赖项(例如第三方模块),提供所有服务并声明所有组件,指令和管道.应用程序需要的越多,该模块就越大.
• 不同的功能在它们之间没有明确的界限,使得更难以理解应用程序的结构,而且对团队负有不同的责任.
• 您可以开始解决应用程序不同部分之间的冲突.例如,如果您的指令或组件在应用程序的两个不同部分中执行相同的操作,则您必须开始使用较长的名称来区分它们或在导入时重命名它们.

虽然你可能认为上面的例子并不完全是问题(也许你单独工作并且可以忍受自己的混乱,或者你的所有队友都很混乱),但请记住,其他人肯定不同意你,这就是为什么你"一直在那里观看几个项目......使用这种方法".

考虑到您同意并希望将不断增长的应用程序组织到功能模块中,请注意以下文档中的声明:

根模块和功能模块共享相同的执行上下文.它们共享相同的依赖注入器,这意味着一个模块中的服务可供所有人使用.

这些模块具有以下重要技术差异:

• 您启动根模块以启动应用程序; 导入功能模块以扩展应用程序.
• 功能模块可以从其他模块公开或隐藏其实现.

永远不会忘记的信息: "一个模块中的服务可用于所有[模块]",而其他内容(如组件,指令和管道)必须注入每个想要使用它们的模块中.

通过这些信息,我们现在可以通过回答以下问题更接近您想要了解的内容:

所有功能模块都相同吗？

没有!至少建议他们不应该相等,因为建议你不应该只有根模块,但你可以做任何你想做的事情.但你不应该.

文档有一个表格,显示建议的功能模块组之间的差异.我们来看一下它的摘录:

FEATURE   SHOULD HAVE    SHOULD HAVE   SHOULD HAVE
MODULE    DECLARATIONS   PROVIDERS     EXPORTS         

Domain    Yes            Rare          Top component   
Routed    Yes            Rare          No              
Routing   No             Yes (Guards)  RouterModule    
Service   No             Yes           No              
Widget    Yes            Rare          Yes             

注意!他们很清楚这是......

......基于在一些应用中使用NgModules的早期经验的初步指导.

所以,再次,你不会坚持这个指导方针,并且可能会发生偏差,但你应该知道你在做什么以及为什么.

现在让我们分析一下这个表:

• 该Service和Widget组是在每列它们之间完全不同的值唯一的.
• 的Domain和Routed基团是基本相同的Widget基团,只具有有限的或没有出口.
• 该Routing组基本上是一个Service组,具有导出例外并且仅限于特定提供者.

所以,让我们考虑一下Domain,Routed并将这些Routing变体组合起来Service或者Widget关注最后两个.

服务应该引起你的注意.请记住,您永远不应忘记"一个模块中的服务可用于所有[模块]"？好吧,如果他们调用功能模块组Services,那是因为它必须与其他模块隔离,因此只能导入一次.举个例子,你可以有一个UserModule是由类似的服务SignUpService,SignInService,SocialAuthService和UserProfileService.无论您在何处导入,UserModule其所有服务都将在应用范围内提供.而根据上表,它不应该有声明,也不应该只有提供者.

小部件听起来更通用,但它应该告诉你一些事情.请记住,您也应该永远不要忘记"其他内容,例如组件,指令和管道必须注入每个想要使用它们的模块中." ？所以这是你将用于那些模块的类型.例如,你可以有一个UIModule用ButtonComponent,NavComponent,SlideshowComponent,HighlightLinkDirective,CtaPipe.每次您需要使用其中一个或所有导出的元素时,只需导入UIModule.

因此,基本上,由于Angular处理服务的方式,当您开始将功能划分为功能模块时,您必须将服务隔离到自己的模块中,而其他内容可以根据您的需要在它们之间进行组织.

怎么做CoreModule并SharedModule适合这个？

为了简单起见,它CoreModule是一个Service模块而且SharedModule是一个Widget模块.这就是为什么你应该AppModule在所有需要它的模块中只导入第一个和后者的原因.从我上面的例子中,UserModule将由CoreModule和UIModule由... 导入SharedModule.

但是,如前所述,这些是准则和偏差可能发生,即使在他们自己的例子中他们声明组件CoreModule,但有一个观察:

此页面示例通过声明和导出[ CoreModule仅]在AppModule声明的根AppComponent中使用的两个组件来脱离该建议.严格遵守本指南的人会在AppModule中声明这些组件.

就个人而言,我认为最大的困惑在于命名选择.一般来说,人们会认为应用程序核心的所有内容(即用户内容,导航栏,加载栏,烤面包机等)都将进入,CoreModule并且多个功能共享的所有内容都会进入SharedModule.

这实际上并不是真的有点误导,因为所有服务都是"本质上"在所有模块之间共享,并且不应该包含任何服务SharedModule,以及NavbarComponent应用程序核心的一部分,并且不应该包含任何组件.CoreModule.

无论如何,建议遵循指南,直到找到不这样做的理由.

以上表格的其余部分有助于更好地理解指南:

FEATURE   CAN BE                 SOME
MODULE    IMPORTED BY            EXAMPLES

Domain    Feature, AppModule     ContactModule (before routing)
Routed    Nobody                 ContactModule, DashboardModule,
Routing   Feature (for routing)  AppRoutingModule, ContactRoutingModule
Service   AppModule              HttpModule, CoreModule
Widget    Feature                CommonModule, SharedModule

干杯!