Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: module registration guidelines 模块注册指导原则 #180

Closed
cipchk opened this issue Jan 6, 2018 · 4 comments
Milestone

Comments

@cipchk
Copy link
Member

@cipchk cipchk commented Jan 6, 2018

一直以来 AppModuleCoreModuleSharedModule 模块使用没有很明确的规范,很容易让产生乱用。Angular模块目标是为了使组件、指令、服务和管道功能块更内聚,并每一个功能区域形成独立的业务领域或实用工具的集合。

AppModule

根模块,用于引导 Angular 启动;它非常适合导入一些需要在整个应用到处需要的模块,例如:主题系统、用户主认证模块、权限模块等模块,以及一些全局性HTTP拦截器、国际化服务等。

CoreModule

核心模块只会被导入一次,它等同 AppModule,但我们更应该把它当成一个纯服务类模块,例如:消息、数据访问等。

SharedModule

我们叫它共享模块;它不应该出现 providers,因为 ShareModule 会在所有业务模块中被导入,这会导致服务被覆盖。

基于以上,这些模块在 ng-alain 中呈现有些混乱,因此将模块更区明确的区分:

AppModule

导入模块:

  • Angular 模块:BrowserModuleBrowserAnimationsModuleHttpClientModule
  • AlainThemeModule 主题系统
  • DelonMockModule Mock数据
  • AlainAuthModule 用户认证模块
  • AlainACLModule 权限模块
  • 国际化模块

包含服务:

  • Angular 国际化
  • HTTP 拦截器
  • Angular 启动服务
  • ng-zorro-antd 基础组件服务
  • ng-zorro-antd-extra 基础组件扩展服务
  • @delon/abc 业务组件服务

作用: 贯穿整个应用的定义。

CoreModule

仅只留 providers 属性。

作用: 一些通用服务,例如:用户消息、HTTP数据访问。

ShareModule

包含定义:

  • 应用通用自定义业务组件

导入模块:

  • Angular 通用模块:CommonModuleFormsModuleRouterModuleReactiveFormsModule
  • ng-zorro-antd 基础组件模块
  • ng-zorro-antd-extra 基础扩展组件模块
  • @delon/abc 业务组件模块
  • 第三方通用依赖组件模块

导出所有包含的模块。

不应providers 属性。

作用: 一些通用自定义、第三方组件定义,减少业务模块的导入。

业务模块

业务模块应该包括业务定义模块和路由模块。

模块

导入模块:

  • SharedModule
  • 对应的路由模块

不应

  • 导出任何组件
  • 尽可能不要使用 providers 属性

路由模块

只包括路由的 importexports 模块。

总结

ng-alain 脚手架将根据以上指导原则做出破坏性变更

@cipchk cipchk added this to the 0.6.0 milestone Jan 6, 2018
@cipchk cipchk closed this in 7b6de51 Jan 8, 2018
cipchk added a commit that referenced this issue Jan 8, 2018
cipchk added a commit that referenced this issue Jan 8, 2018
- update third libs to laster version
cipchk added a commit that referenced this issue Jan 8, 2018
- update third libs to laster version
@justein

This comment has been minimized.

Copy link

@justein justein commented Jun 1, 2018

get it!

@tc9011

This comment has been minimized.

Copy link

@tc9011 tc9011 commented Aug 20, 2018

@cipchk hi, 卡色老师好,之前对ng项目都是凭着自己对官方指导的理解去组织模块,最近看了ng-alain源码和对模块的划分,收货很多。不过对业务模块尽可能不要使用 providers 属性有些疑问,官方有个指导是:

坚持把数据操作和与数据交互的逻辑重构到服务里。

坚持让数据服务来负责 XHR 调用、本地储存、内存储存或者其它数据操作。

我也经常在项目中碰到组件内需要做一些比较复杂的数据计算,一般我会把这些放在服务里面,这样组件更加干净一点,并且对于业务模块中的http请求都会封装在服务中,对应组件只负责调用就行,这导致业务相关的模块都会有自己的一个服务。

但是如果按照ng-alain的模块指导原则,这些服务的放置问题就会比较尴尬。我查看了ng-alain的源码,这些http的请求都写在组件中,所以有些疑问,如何比较好的处理这个问题。谢谢。

@cipchk

This comment has been minimized.

Copy link
Member Author

@cipchk cipchk commented Aug 20, 2018

ng-alain 有点我个人色彩习惯在里面,所以与官网有点不太一样,其实核心是在于组件类是重还是轻,就中台而言可重用有限且可测试性的要求可能跟团队的关系有些着重点不同。

不管是官网还是 ng-alain 的指导原则选择一项你觉得最合理的那就是对的。

虽然 ng-alain 的有自己的模块指导原则,但对于业务层面并没有任何的强制,采用哪一种取决于你的团队环境。

@tc9011

This comment has been minimized.

Copy link

@tc9011 tc9011 commented Aug 20, 2018

@cipchk 恩恩,好的,感谢解答

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.