Question

请问有人可以给我一些有关我的项目结构的建议吗？

-app
  -layout
     -home-layout
         -header
         -menu
         -content
            -detail-page
               -left-side
                  -left-side.component.html
                  -left-side.component.ts
               -right-side
             -detail-page.component.html
             -detail-page.component.ts
         -footer
     -pipes
     -widget-features
  -material-module
  -services
  -models

使用实际结构，站点地图的组织非常聪明，我可以轻松地找到不同页面的内容。但是要获得模块化架构，我想重新组织结构。你能给我一些建议吗？

谢谢。

Answer 1

我喜欢本文推荐的结构[Angular文件夹结构] https://medium.com/@motcowley/angular-folder-structure-d1809be95542，但是经过一些修改，我们公司最终得到以下结果：

-app
  
 -shared
     -services
     -pipes
     -components
     -models

-modules
  -users
    -components
        -list
        -edit
    -models
        -users.model.ts
    -services
        -user-service.ts

    users.component.ts // this component should act like a container/smart component
    users.component.html
    users.component.module.ts
    users.component.module.ts
    users.component.route.ts

  -organisations
    -components
        -list
        -manage
    -models
        organisation.model.ts
    -services
        organisation.service.ts
        
    organisations.component.ts  // this component should act like a container/smart component
    organisations.component.html
    organisations.component.module.ts
    organisations.component.module.ts
    organisations.component.route.ts

-app.component.ts
-app.component.html
-app.module.ts
-app-routing.module.ts

这也提供了一种微服务架构，其中每个模块/功能都有自己的服务/依赖关系。

Answer 2

请记住，没有适用于所有项目的魔术子弹或通用配方。

那表示您可以使用官方的Angular Style Guide，它会尝试遵循Folders-by-feature structure。

关于应用程序结构，您必须牢记LIFT：

对应用进行结构设计，以便您可以 L 快速定位代码，我识别浏览代码，保持 F 最新的结构，然后 T 变干

L 定位

使定位代码直观，简单，快速。

我识别

对文件进行命名，以使您立即知道其中包含的内容，   代表。

使用文件名进行描述，并将文件内容保留为   只是一个组成部分。

避免使用包含多个组件，多个服务或混合文件的文件。

F lat

请尽量保持平面文件夹结构。

考虑在文件夹达到七个或更多时创建子文件夹   文件。

考虑将IDE配置为隐藏分散注意力的无关文件   例如生成的.js和.js.map文件。

T 要变干

做干（别重复自己）。

避免过于干燥而牺牲可读性。

根据您显示的结构，可能值得回顾的一件事是遵循Do keep a flat folder structure as long as possible原则的文件夹嵌套级别。

这意味着您应该使结构尽可能平整，这样可以更快地找到文件。但这不是必须的规则，而是应该的规则。因此，如果使结构更平坦不影响您当前拥有的逻辑组织，则可能应该使它更平坦（否则就不应该）。

请记住这旨在改善开发过程：如果某项措施无法改善您的团队组织/生产力等，则不要使用它，如果有帮助，请使用它。

>

Answer 3

Angular Style Guide所遵循的体系结构称为“功能模块”体系结构，其中功能封装在Angular模块（带有@ngModule装饰器的TypeScript类）中。

要对此有所了解，请尝试使用Angular CLI运行一些generate命令。

例如，要创建包含一些封装的组件/服务的功能模块，请依次运行以下命令：

ng g m my-awesome-feature
ng g c my-awesome-feature/cool-component
ng g s my-awesome-feature/fancy-service

CLI将为您创建一个不错的模块架构，甚至自动在模块文件中声明您的组件！

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { CoolComponentComponent } from './cool-component/cool-component.component';

@NgModule({
  imports: [
    CommonModule
  ],
  declarations: [CoolComponentComponent]
})
export class MyAwesomeFeatureModule { }

Answer 4

我认为，我始终遵循类似的结构，该结构将基于url的结构和模块化体系结构的优点结合在一起。就像这样：

应用
- _models
- _services
- _shared
  - 共享的组件
  - 共享模块
- 家
- 任何页面
  - 具体组成部分

基本上，在“ _shared”中，您将放置所有在不同页面之间共享的组件和模块，例如页脚或Material模块。您必须声明它们或将它们导入_shared模块，以及导出它们。

我假设所有服务都是在app模块中共享和提供的，但是您当然可以将它们放在_shared模块或任何其他子模块中。

顺便说一句，我用实际的下划线命名它们，以便它们在浏览器中冒泡。知道他们总是会在那里很方便。

Answer 5

here is an entire article from medium where you will found useful advice for your angular project

使用共享模块：简而言之，当使用共享模块时：务必声明组件、管道、指令并导出它们。务必导入 FormsModule、ReactiveFormsModule 和您需要的其他（第 3 方）模块。务必将 SharedModule 导入任何其他功能模块。不要在您的 SharedModule 中提供应用程序范围的单例服务。相反，将这些移动到 CoreModule。请勿将 SharedModule 导入 AppModule。
使用核心模块：简而言之，当使用核心模块时：务必导入应在您的应用程序中实例化一次的模块。一定要在模块中放置服务，但不要提供它们。不要声明组件、管道、指令。请勿将 CoreModule 导入除 AppModule 之外的任何模块。
简化您的导入：
缩短相对路径
使用 SCSS 变量

角项目结构最佳实践

5 个答案: