Angular(5)项目：视图路由划分用NgModules还是页面组件？

嘿，针对你这个Angular 5项目的结构划分问题，我绝对推荐用NgModules来做组织——这完全符合Angular的设计理念，也是长期来看可维护性、扩展性最优的方案，比单纯用组件堆砌页面靠谱多了。

为什么选NgModules而非纯组件？ #

说白了，NgModules就是Angular里的“业务单元容器”：

• 它能把同一业务域的组件、服务、路由、甚至第三方依赖封装在一起，做到关注点彻底分离，团队协作时不会出现代码交叉混乱的情况；
• 支持懒加载，用户访问到某个板块时才加载对应模块的代码，大幅优化项目的初始加载速度，这点对你现在有多个业务板块的项目来说特别有用；
• 模块本身具备复用性，如果以后其他子系统需要用到MONITOR或DATA ANALYSIS的功能，直接导入对应模块就行，不用复制粘贴代码；
• 可以控制对外暴露的内容，内部的实现细节（比如子组件、私有服务）不用给其他模块开放，降低模块间的耦合度。

具体结构划分方案 #

1. 核心模块与共享模块（基础支撑） #

先搭好基础模块：

• CoreModule：放全局唯一的服务（比如认证服务、HTTP拦截器、全局配置服务）、根级别组件（比如导航栏、页脚），这个模块只在根模块AppModule里导入一次，不要在特性模块中重复导入；
• SharedModule：封装所有模块共用的通用组件（比如通用表格组件、通用表单组件）、管道、指令，还有第三方库的导入（比如Angular Material的基础模块），每个特性模块需要用到这些通用元素时，直接导入SharedModule即可。

2. 特性模块对应业务板块 #

你的每个一级导航项（HOME、MONITOR、SCHEDULE等）都应该做成独立的特性模块，每个模块内部再拆分页面/子组件：

• HomeModule：对应HOME页面，因为没有子页面，直接包含一个HomeComponent作为页面级组件即可；
• MonitorModule：对应MONITOR板块，内部包含两个页面组件：
  • MonitorSubpage1Component（负责展示表格）
  • MonitorSubpage2Component（负责展示表格）
    另外，如果两个子页面的表格有共性逻辑，比如相同的分页、筛选规则，可以在模块内再拆一个MonitorTableComponent作为复用子组件，同时模块内可以放专属的MonitorDataService来处理该板块的数据请求；
• ScheduleModule：对应SCHEDULE板块，包含：
  • ScheduleSubpage1Component（表格页面）
  • ScheduleSubpage2Component（表单页面）
    表单如果有通用的表单控件逻辑，也可以拆成子组件放在模块内；
• DataAnalysisModule：对应DATA ANALYSIS板块，包含：
  • DataAnalysisSubpage1Component（双表格页面）
  • DataAnalysisSubpage2Component（表格页面）
    这里双表格可以拆成两个独立的表格子组件，让页面组件更简洁；
• DataQualityModule：对应DATA QUALITY板块，包含：
  • DataQualitySubpage1Component（表单页面）
  • DataQualitySubpage2Component（表格页面）
• ConfigurationModule：如果CONFIGURATION有子页面，按上述逻辑拆分页面组件；如果没有，直接用ConfigurationComponent作为页面组件；
• UserSetupModule：同理，对应USER SETUP的页面组件，有子页面就拆分，没有就单个页面组件。

3. 路由配置实现懒加载 #

每个特性模块都要配置自己的路由模块（比如MonitorRoutingModule），然后在根路由AppRoutingModule里通过loadChildren实现懒加载，示例代码如下：

// app-routing.module.ts
const routes: Routes = [
  { path: '', redirectTo: 'home', pathMatch: 'full' },
  { path: 'home', loadChildren: './home/home.module#HomeModule' },
  { path: 'monitor', loadChildren: './monitor/monitor.module#MonitorModule' },
  { path: 'schedule', loadChildren: './schedule/schedule.module#ScheduleModule' },
  // 其他模块路由依此类推
];

模块的必要性：绝对值得考虑 #

不要觉得模块是多余的，哪怕现在项目规模不算特别大，模块带来的好处会随着项目扩展越来越明显：

• 代码结构清晰，新人接手能快速定位到对应业务板块的代码；
• 懒加载优化性能，用户不用加载所有模块的代码就能使用核心功能；
• 封装性让你可以放心修改某个模块的内部逻辑，不用担心影响其他板块；
• 复用性减少重复代码，降低维护成本。

举个具体的模块目录结构例子（以MonitorModule为例）：

monitor/
├── monitor.module.ts
├── monitor-routing.module.ts
├── components/
│   ├── monitor-subpage1/
│   │   ├── monitor-subpage1.component.ts
│   │   ├── monitor-subpage1.component.html
│   │   └── monitor-subpage1.component.css
│   ├── monitor-subpage2/
│   │   ├── monitor-subpage2.component.ts
│   │   ├── monitor-subpage2.component.html
│   │   └── monitor-subpage2.component.css
│   └── shared/
│       └── monitor-table/
│           ├── monitor-table.component.ts
│           └── monitor-table.component.html
└── services/
    └── monitor-data.service.ts

内容的提问来源于stack exchange，提问作者JSDoe