【问题标题】:Nestjs Dependency Injection and DDD / Clean ArchitectureNestjs 依赖注入和 DDD / 清洁架构
【发布时间】:2019-03-28 20:54:57
【问题描述】:

我正在通过尝试实现一个干净的架构结构来试验 Nestjs,我想验证我的解决方案,因为我不确定我是否理解最好的方法。 请注意,该示例几乎是伪代码,并且很多类型都缺失或泛型,因为它们不是讨论的重点。

从我的领域逻辑开始,我可能想在如下类中实现它:

@Injectable()
export class ProfileDomainEntity {
  async addAge(profileId: string, age: number): Promise<void> {
    const profile = await this.profilesRepository.getOne(profileId)
    profile.age = age
    await this.profilesRepository.updateOne(profileId, profile)
  }
}

这里我需要访问profileRepository,但是遵循干净架构的原则,我不想为刚才的实现而烦恼,所以我为它写了一个接口:

interface IProfilesRepository {
  getOne (profileId: string): object
  updateOne (profileId: string, profile: object): bool
}

然后我在 ProfileDomainEntity 构造函数中注入依赖项,并确保它遵循预期的接口:

export class ProfileDomainEntity {
  constructor(
    private readonly profilesRepository: IProfilesRepository
  ){}

  async addAge(profileId: string, age: number): Promise<void> {
    const profile = await this.profilesRepository.getOne(profileId)
    profile.age = age

    await this.profilesRepository.updateOne(profileId, profile)
  }
}

然后我创建了一个简单的内存实现,让我运行代码:

class ProfilesRepository implements IProfileRepository {
  private profiles = {}

  getOne(profileId: string) {
    return Promise.resolve(this.profiles[profileId])
  }

  updateOne(profileId: string, profile: object) {
    this.profiles[profileId] = profile
    return Promise.resolve(true)
  }
}

现在是时候使用模块将所有东西连接在一起了:

@Module({
  providers: [
    ProfileDomainEntity,
    ProfilesRepository
  ]
})
export class ProfilesModule {}

这里的问题是 ProfileRepository 显然实现了 IProfilesRepository 但它不是 IProfilesRepository 因此,据我了解,令牌不同,Nest 无法解决依赖关系。

我发现的唯一解决方案是使用自定义提供程序来手动设置令牌:

@Module({
  providers: [
    ProfileDomainEntity,
    {
      provide: 'IProfilesRepository',
      useClass: ProfilesRepository
    }
  ]
})
export class ProfilesModule {}

并通过指定要与@Inject 一起使用的令牌来修改ProfileDomainEntity

export class ProfileDomainEntity {
  constructor(
    @Inject('IProfilesRepository') private readonly profilesRepository: IProfilesRepository
  ){}
}

这是处理我所有依赖项的合理方法还是我完全偏离了轨道? 有没有更好的解决方案? 我对所有这些东西都很陌生(NestJs、干净的架构/DDD 和 Typescript),所以我在这里可能完全错了。

谢谢

【问题讨论】:

  • 使用抽象类(+无默认功能)而不是接口(+字符串提供者)有什么好处?或相反。

标签: typescript dependency-injection domain-driven-design nestjs clean-architecture


【解决方案1】:

导出一个符号或字符串以及同名的接口

export interface IService {
  get(): Promise<string>  
}

export const IService = Symbol("IService");

现在你基本上可以使用IService作为接口和依赖令牌了

import { IService } from '../interfaces/service';

@Injectable()
export class ServiceImplementation implements IService { // Used as an interface
  get(): Promise<string> {
    return Promise.resolve(`Hello World`);
  }
}
import { IService } from './interfaces/service';
import { ServiceImplementation} from './impl/service';
...

@Module({
  imports: [],
  controllers: [AppController],
  providers: [{
    provide: IService, // Used as a symbol
    useClass: ServiceImplementation
  }],
})
export class AppModule {}
import { IService } from '../interfaces/service';

@Controller()
export class AppController {
  // Used both as interface and symbol
  constructor(@Inject(IService) private readonly service: IService) {}

  @Get()
  index(): Promise<string> {
    return this.service.get(); // returns Hello World
  }
}

【讨论】:

    【解决方案2】:

    我使用了一种不同的方法来帮助防止跨多个模块的命名冲突。

    我使用字符串标记和自定义装饰器来隐藏实现细节:

    // injectors.ts
    export const InjectProfilesRepository = Inject('PROFILES/PROFILE_REPOSITORY');
    
    // profiles.module.ts
    @Module({
      providers: [
        ProfileDomainEntity,
        {
          provide: 'PROFILES/PROFILE_REPOSITORY',
          useClass: ProfilesRepository
        }
      ]
    })
    export class ProfilesModule {}
    
    // profile-domain.entity.ts
    export class ProfileDomainEntity {
      constructor(
        @InjectProfilesRepository private readonly profilesRepository: IProfilesRepository
      ){}
    }
    

    虽然比较冗长,但可以安全地从同名的不同模块导入多个服务。

    【讨论】:

      【解决方案3】:

      您确实可以使用接口,以及抽象类。一个打字稿功能是从类(保存在 JS 世界中)推断接口,所以这样的东西可以工作

      IFoo.ts

      export abstract class IFoo {
          public abstract bar: string;
      }
      

      Foo.ts

      export class Foo 
          extends IFoo
          implement IFoo
      {
          public bar: string
          constructor(init: Partial<IFoo>) {
              Object.assign(this, init);
          }
      }
      
      const appServiceProvider = {
        provide: IFoo,
        useClass: Foo,
      };
      
      

      【讨论】:

      • 是的,您只需要实施即可。
      • 使用抽象类(+无默认功能)优于接口(+字符串提供者)有什么好处?或相反。
      • 在这种情况下,您将需要使用抽象类将其(因此引用 DI)保留在 JS 世界中,因为接口根本不会被转译
      【解决方案4】:

      由于语言限制/功能(see structural vs nominal typing),无法resolve dependency by the interface in NestJS

      而且,如果您使用接口来定义(类型)依赖项,那么您必须使用字符串标记。但是,你也可以使用类本身,或者它的名字作为字符串字面量,所以你不需要在注入过程中提到它,比如依赖的构造函数。

      例子:

      // *** app.module.ts ***
      import { Module } from '@nestjs/common';
      import { AppController } from './app.controller';
      import { AppService } from './app.service';
      import { AppServiceMock } from './app.service.mock';
      
      process.env.NODE_ENV = 'test'; // or 'development'
      
      const appServiceProvider = {
        provide: AppService, // or string token 'AppService'
        useClass: process.env.NODE_ENV === 'test' ? AppServiceMock : AppService,
      };
      
      @Module({
        imports: [],
        controllers: [AppController],
        providers: [appServiceProvider],
      })
      export class AppModule {}
      
      // *** app.controller.ts ***
      import { Get, Controller } from '@nestjs/common';
      import { AppService } from './app.service';
      
      @Controller()
      export class AppController {
        constructor(private readonly appService: AppService) {}
      
        @Get()
        root(): string {
          return this.appService.root();
        }
      }
      

      您也可以使用抽象类而不是接口,或者为接口和实现类指定一个相似的名称(并就地使用别名)。

      是的,与 C#/Java 相比,这可能看起来像是一个肮脏的 hack。请记住,接口只是设计时的。在我的示例中,AppServiceMockAppService 甚至没有继承自接口或抽象/基类(在现实世界中,它们当然应该),只要它们实现方法 root(): string,一切都会正常工作。

      引用the NestJS docs on this topic:

      通知

      我们使用了 ConfigService 类而不是自定义令牌,因此我们覆盖了默认实现。

      【讨论】:

        猜你喜欢
        • 2017-03-20
        • 1970-01-01
        • 2021-12-01
        • 2020-12-12
        • 2018-07-13
        • 2021-04-23
        • 2021-04-06
        • 2021-01-22
        • 1970-01-01
        相关资源
        最近更新 更多