既然 ProvideIn 是一个选项,那么 CoreModule 模式是否有理由?

Is there a reason for the CoreModule pattern now that ProvideIn is an option?

根据我的理解,CoreModule 的原因是拥有初始化应用程序所需的所有东西,并且还包含要在应用程序中的所有模块之间共享的服务(HttpInterceptors、AuthenticationService 等) ).现在我们有 provideIn: 'root',还有理由再拥有 CoreModule 吗?现在不推荐使用这种模式吗?是否有一个用例,我们仍然可能希望有一个 CoreModule 来保存所有或部分共享服务?

You can checkout angular style guide: https://angular.io/guide/styleguide#core-feature-module.

一个原因是概念的分离,coreModule 必须只有模块、提供者、组件,其他的应该只在 appModule 中,而不应该在应用程序的任何其他模块中。这也有助于您使应用程序模块更清洁。

这里可以设置HttpClientModule,HTTP_INTERCEPTORS,BrowserAnimationsModule,其他

您还可以查看我实施 angular 风格指南建议的项目,例如核心模块:here

根据, no. Here is a PR with some more discussion

@jenniferfell @brandonroberts fyi. @jenniferfell we removed CoreModule as a recommended technique because now the preferred way of providing services is using providedIn, however @bisonfoutu has a great point. I think the focus of this issue might be best suited for a style guide point on Feature Modules or SharedModule section, but I'd love to hear what the team and community have to say.

在同一期中,John Papa 解释了 why you might still want to use it

This is all great feedback. Now that services can be provided in the root using providedIn it does make it easier to put services where they are needed.

However, the CoreModule was never intended to be a place to put services that should only be defined and used in a sub-ngmodule. So here are my thoughts on this, with some questions to consider.

My domain here is to consider app-wide services. Not ones used only in a sub-ngmodule. What about services used app-wide by needing to be defined in a sub module? Let's hold off on that for a moment.

First - app-wide stuff in the root ...

  1. When you have a dozen or so services that are used by the entire app, would you really want to declare them all over the place or in a single place?
  2. If the answer to #1 is "yes" then would that place be AppModule? If so, are you comfortable with having a dozen or so of them defined there? Possibly.
  3. Would these app wide services be useful in other apps? If so, a Core module can make it easier to test and find these. CoreModule helps here
  4. Would these app wide services be good candidates to other apps via an npm library? If so, I might suggest a npm module and not an specific module (via the Angular CLI)

I do think there is some value for a CoreModule for organizational purposes. (see above)

But ... what about a service that a sub module needs and some other one might need. Could you define that in a sub module? Well, you could ... let's walk through that. Assume we have a Customer ngmodule and we define a CustomerService that gets and puts customer data and it uses providedIn to the root. Now another module needs Customer data. You could still use it in that other ngmodule, let's say it handles Orders. So the ngOrders module now uses a service that is provided in the root, but exists in the Customer Module. This works. But is is clear? Is it readable?

New questions based on this new scenario ... How does lazy loading of OrdersModule work now that it depends on a service in the CustomersModule (which is provided in the root)? Is it confusing? What happens if you re-use OrdersModule in another app? It has a dependency that you now need to track down?

IMO - any app-wide "things" should be easily findable. Thus the concept (not the name though) of a CoreModule is still valid and I still use it.

Hope this helps :)

我认为关键要点是,是否使用核心模块取决于您,但您确实希望确保不在共享模块中包含服务,该模块会多次重新导入次,因为这将重新实例化它们。