这个问题来自企业应用程序的上下文。
从我阅读的所有书籍和有关角度应用程序的在线示例中，每次我们创建类（组件，服务，实体等）时，我们都会根据类型定义导出它们，然后将其直接导入到需要的任何位置引用（类似于在C＃上使用名称空间），无论两个类都属于相同或不同的angular模块。
例如：
// 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 { ... }
鉴于此方法比以前的方法冗长得多，并且在某些情况下会引起尴尬的结果（如果在同一模块中导入类，则会出现循环引用警告）
我的问题是：
这是一个称为“桶形文件”的概念。这些文件使导入类更加方便。对于Angular而言，这并不是一个概念。在TypeScript中使用它们似乎是最佳实践。
当您有一个较小的项目时，创建这些文件可能不会带来太多好处，但是当与多个团队成员一起进行较大的项目时，它们会非常有用。以下是我知道的一些优点/缺点。
优点：较少的模块内部知识
当一个组件需要引用某个东西时，它就不必知道类等在哪个文件中。当您不对模块中的东西进行打包时，则该模块之外的所有其他文件都将需要确切知道哪个文件（包括子路径）包含该项目。如果将物品装入单个模块桶中，则只需要知道它来自哪个模块即可。这也给您带来了重构模块的好处，即不需要在文件移动时确保更新路径（您的工具可能会也可能不会对此有所帮助）。
// without barrel files
import { Class1 } from 'app/shared/module1/subpath1/subpath2/class1.service';
// using barrel files
import { Class1 } from 'app/shared/module1';
Pro：明确导出外部模块
另一个好处是，一个模块可能包含一堆类，接口等，这些类，接口等实际上只打算在该模块中使用。通过为模块创建桶文件，您可以让其他开发人员知道在模块外部使用的含义。此外，您还让他们确切地知道要使用哪些项目，因此他们无需四处寻找所需的接口（同样，您的工具可能会也可能不会这样做）。
// 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';
缺点：附加文件
在尝试确定缺点时，我唯一想到的就是您正在为每个模块创建另一个文件（或者可能是子文件夹，具体取决于您要执行的操作）。据我所知，它没有运行时或编译时的影响。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句