如何跨角度模块正确导入/导出类？

这个问题来自于企业应用的背景。

从我读过的所有书籍和我见过的关于角度应用程序的在线示例中，每次我们创建一个类（组件、服务、实体等）时，我们都会在类型定义上导出它们，然后在需要的地方直接导入它们引用（类似于在 C# 上使用命名空间），无论两个类属于相同或不同的 Angular 模块。

Ex:

// In 'Commons/logger.service.ts'
export class LoggerService { ... }

// In 'Core/common.service.ts'
export class CommonService { ... }

// In 'Products/' module
import { LoggerService } from '../Commons/logger.service'
import { CommonService } from '../Core/common.service'

export class ProductComponent { ... }

我开始从事一个（大型）企业应用程序项目，并注意到一种我以前从未见过的方法，他们创建文件来收集每种类型的类（服务、实体、方法参数、组件），导出其中的每一个，导出其中的每一个这些文件位于其相应的角度模块文件上，然后不是直接从类型文件导入类型，而是从给定模块执行导入。

前面的示例将转换为如下所示：

// In 'Commons/logger.service.ts'
export class LoggerService { ... }

// In 'Commons/services.ts'
export * from './logger.service.ts'
export * from './other.service.ts'
export * from './another.service.ts'

// In 'Commons/commons.module.ts'
export * from 'services.ts'
export * from 'entities.ts'
/* ... */


// In 'Products/' module
import { LoggerService, OtherService } from '../Commons/commons.module'

export class ProductComponent { ... }

鉴于这种方法比以前的方法要详细得多，并且在某些情况下会引起尴尬的结果（如果在同一模块中导入类，则会出现循环引用警告）

我的问题是：

1. 从良好设计或最佳实践的角度来看，推荐哪种方法？
2. 是否比前者更推荐这种方法？为什么？适用于哪些情况？
3. 为什么这种方法没有在主要文档来源（Angular 在线文档、Angular 书籍等）中引入？
4. 这种方法的优点和缺点是什么。

这是一个称为桶文件的概念。这些文件使导入类更加方便。这不仅仅是 Angular 的一个概念。使用它们似乎是 TypeScript 的最佳实践。

当您有一个较小的项目时，您可能看不到创建这些文件的太多好处，但是当您与多个团队成员一起处理较大的项目时，它们会非常有用。以下是我所知道的一些优点/缺点。

优点：模块内部结构所需的知识较少

当组件需要引用某些内容时，它不必知道类等所在的确切文件。当您不将这些内容存储在模块内时，模块外部的所有其他文件都将需要确切地知道哪个文件（包括子路径）包含该项目。如果您将物品放入单个模块桶中，您只需知道它来自哪个模块即可。这还为您带来了重构模块的好处，不需要您确保在文件移动时更新路径（您的工具可能会或可能不会帮助解决此问题）。

// without barrel files
import { Class1 } from 'app/shared/module1/subpath1/subpath2/class1.service';

// using barrel files
import { Class1 } from 'app/shared/module1';

优点：显式导出外部模块

另一个好处是，一个模块可能包含一堆类、接口等，这些类、接口等实际上只在该模块内使用。通过为模块创建桶文件，您可以让其他开发人员知道在模块外部使用的内容。此外，您让他们确切地知道要使用哪些项目，因此他们不需要到处寻找他们需要的界面（同样，您的工具可能会或可能不会对此提供帮助）。

// export these items from module as others need to have references to these
export { ExampleModule } from './example.module';
export { ExampleService } from './example.service';
export { ExampleInterface } from './example.model';

// these also exist in module but others don't need to know about them
// export { ExampleComponent } from './example.component';
// export { Example2Service } from './example2.service';
// export { ExampleInterface2 } from './example.model';

优点：更清洁的进口

我要提到的最后一个好处是它有助于清理您的进口。它不仅可以更清楚地显示哪些项目来自哪些模块，还有助于使from导入的部分要短得多，因为您不需要遍历子目录等。请注意，最佳实践似乎是将桶文件index.ts位于文件夹中，因为当给定要从中导入的文件夹时，TypeScript 编译器将默认查找该文件。

// without barrel files (hopefully they would be not randomly ordered to make it even harder...)
import { Class1 } from 'app/shared/module1/subpath1/subpath2/class1.service';
import { Class2 } from 'app/shared/module1/subpath1/class2.component';
import { Interface1 } from 'app/shared/module1/module1.model';
import { Class3} from 'app/shared/module2/subpath3/class3.service';
import { Interface2 } from 'app/shared/module2/module2.model';

// using barrel files
import { Class1, Class2, Interface1 } from 'app/shared/module1';
import { Class3, Interface2 } from 'app/shared/module2';

缺点：附加文件

在尝试识别缺点时，我唯一能想到的是您正在为每个模块创建另一个文件（或者可能是子文件夹，具体取决于您想要如何执行此操作）。据我所知，它没有运行时或编译时效果。