在 class / 纯函数中注入服务

Question

我正在从事 Angular 项目（Angular 14+）并遵循原子设计原则（创建分钟级组件，如按钮、输入、切换等）。

大多数视图（列表、forms、标题）基于来自服务器的 JSON（说明组件的内容和位置）。 服务器还发送 function enums来执行特定功能。 例如，在按钮上单击导航到特定屏幕，或打开特定模式并采取用户操作并点击 API 等。这些功能（基于 JSON 的 function 枚举）分布在整个应用程序中（可以出现在任何嵌套级别） .

所以为了简单起见，我选择了两种方法：

1. TypeScript class 基础函数（组件模型）
2. 纯函数（简单的导入/导出）

现在在编写这些函数时，需要访问一些服务和第三方组件，如 Modal 参考、snackbar 参考、路由器参考或 HTTP 服务。

为了避免 Angular DI 或其他框架代码，我采用了 angular 注入器的全局引用（ injector()函数）并创建了一个全局 singleton TS class，其中包含 HTTP、modal、snackbar、 modalRef 、router、 snackbarRef HTTPRef一组属性, routingRef ) 并为它们分配所需的服务或组件引用。

现在我可以在简单的类或纯函数中使用它们，例如

// pure function example:
const openModal<T>(componentRef: ComponentType<T>, componentData?: any, dialogConfig?: MatDialogConfig, closeCB?: FunctionCall){
const dialogRef = globalConfig.matDialogRef; // singelton class ref
    const openDialogRef = dialogRef.open(component,{
    data: componentData
  });
  return { dialogRef, openDialogRef };
}

类似的其他功能全局依赖，它帮助我调用 TS 普通类（组件模型）。

这些全局 Ref 的创建如下：

AppModule ---> InitializerModule --> calling TS class methods

例如

<!-- InitializerModule -->
// all imports
export let NGInjectorInstance: Injector; ----- [A]
// some more code
export class InitializerModule {
  constructor(private injector: Injector) {
    NGInjectorInstance = this.injector; // injector reference
    CLIENTS_INIT(); // calling classes init functions
    GLOBAL_INIT(); // same here, will use global injector inside these classes to assign references 
  }
}

班级：

GLOBAL_INIT() ---> /src/models/config/index.ts

// index.ts 
import { default as GlobalConfig } from "./global.config"; // singelton class
export const globalConfig = GlobalConfig;

export default () => {
    globalConfig.initSnackBarDeps();
    globalConfig.initMatDialogDeps();
    globalConfig.initRouterDeps();
    globalConfig.initHTTPDeps();
    globalConfig.initStoreDeps();
}


public initMatDialogDeps(){
        this.matDialogRef =  NGInjectorInstance.get<MatDialog>(MatDialog);
}

我在这里读到，向独立的 class 注入服务是一种反模式， 在这里，向 class 注入服务被认为是反模式。 因此，即使我应该如何验证它我可以偏离/弯曲多少以遵循这种方法（我也同意多少是非常主观的并且需要更多上下文）。 是要整体抛弃还是还有空间可以跟进？

Answer 1

为什么在需要使用 DI 时要尽量避免使用它？

DI 可能是目前使用最广泛的模式，因为它有很多好处。 全球 static 的东西已经在 window 之外多年了，因为它让测试变得很痛苦。

当然，您不必使用 DI，就此而言，您也不必使用Angular 的DI。 如果您只是习惯于注入依赖项，那么由谁来实现并不重要，因此您始终可以自己做； 然后 class 可以在组件内或通过其他方式使用，然后可以对其进行适当的模拟和测试等。

在您的第一个链接中，它专门讨论了实现组件和服务创建以及填充依赖项的框架，但是如果您正在创建实例，您可以自己完成。

正如您发现的那样，在此过程中的某个地方，您需要来自某处的服务并使用它们。 然后，最重要的是，您需要在一天结束时在您的组件中使用这些服务——另一个您可以访问这些服务的地方。

现在，你正在竭尽全力避免……某事，并让自己更难。

为了简化事情，一种选择是您可以将它们全部组合起来并拥有一个FunctionProvider服务。

这个服务是把所有的必需品都注入进去，它可以返回成品（功能）给消费者使用。 消费者永远只需要注入这个FunctionProvider而不必担心它在幕后需要的一切（因为 DI 会为你分类）。

然后您可以将其传递到您的“独立”类中供他们使用 - 提供者由 Angular DI 提供到您的组件中，但您的组件肯定会获得创建和使用您的独立类的所有权 - 因此它可以传递它一起使用。

基本版本可能如下所示：

@Injectable()
export class FunctionProvider {
    constructor(private readonly http: HttpClient,
                private readonly matDialog: MatDialog) {}

    public get(fnType: FunctionTypeEnum): any {
        switch (fnType) {
            case FunctionTypeEnum.OpenDialog:
                return this.openDialogFn();
        }
    }

    private openDialogFn(): any {
        return (component, data) => {
            return this.matDialog.open(component, {data});
        };
    }
}

Class 在某些时候可能会变得相当大，您可能会将每个 function 提供者移动到他们自己的助手 class 或其他东西 - 以及您选择如何提供服务（坚持使用构造函数，或传递给方法本身）......

export class OpenDialogFnProvider {
    constructor(private readonly matDialog: MatDialog) {}

    public get(): (component, data) => Observable<Bleh> {
        return (component, data) => this.matDialog.open(component, {data});
    }
}

所以你的开关条目变成了你创建 class：

case FunctionTypeEnum.OpenDialog:
    return new OpenDialogFnProvider(this.matDialog).get();

然后使用它：

export class SomeComponent {
    constructor(private readonly fnProvider: FunctionProvider) {}

    public onClick(): void {
        const fn = this.fnProvider.get(FunctionTypeEnum.OpenDialog);
        fn(SomeDialogComponent, {title: 'test'});
    }
}

在所有这一切之后，无论如何，您都有一个 function，您可以随心所欲地使用它。 Component 获取它，然后将其传递给一个可能会进行一些处理的纯 class - 函数可以像任何其他变量一样传递，所以我不确定你是否节省了任何努力，或者通过尝试让任何人的生活更轻松避免使用可用的机制。

也许我只是没有正确理解您的问题以及您要做什么。