[Feature request] 事件驱动

[ghostoy]

The feature, motivation（功能、动机）

需要一个中心的事件触发器，将Service之间进行解耦。支持同步触发和异步触发。

建议实现方式：

@Provide()
class MyServiceA {
  @Inject()
  eventEmitter: MidwayEventEmitter;

  // 用MidwayEventEmmitter触发
  async someMethod() {
    // 同步触发事件
    this.eventEmitter.emit('foo', args);
    // 异步触发事件
    await this.eventEmitter.emitAsync('bar', args);
  }

  // 用装饰器触发
  @Emit('foo') // 默认在调用后将返回值作为触发参数
  @EmitAsync('bar') // 异步触发，等待触发完成后再返回原始函数返回值
  async emitWithDecorator() {}
}

@Provide()
class MyClassB {
  @Event('foo')
  onFoo(args: any) {
    // 处理foo事件
  }

  @Event('bar')
  onBar(args: any) {
    // 处理bar事件
  }
}

Alternatives（替代方案）

现在可以实现一个类似的单例服务(EventService)，注入到其他单例服务中。例如：

@Singleton()
class EventService {
  emit(evtName: string, ...args: any[]) {}
  async emitAsync(evtName: string, ...args: any[]) {}
  on(eventName: string, handler: (...args: any[]) => any) {}
  once(eventName: string, handler: (...args: any[]) => any) {}
  off(eventName: string, handler?: (...args: any[]) => any) {}
}

// 这里必须是单例
// * 只有通过单例模式才能保证Init和Destroy全局只能执行一次
// * 只有单例模式才会在启动框架时创建，保证触发事件时所有的监听器已经执行过注册
@Singleton()
class MyServiceB {

  @Inject()
  eventService: EventService;

  @Init()
  onInit() {
    // 注册监听
    this.eventService.on('foo', this.onFoo);
    this.eventService.on('bar', this.onBar);
  }

  @Destroy()
  onDestroy() {
    // 解除监听
    this.eventService.off('foo', this.onFoo);
    this.eventService.off('bar', this.onBar);
  }

  onFoo: (args: any) => {} // 使用箭头函数保证this的正确指向
  onBar: (args: any) => {}
}

Additional context（其他上下文）

No response

[ghostoy]

替代方案有很多问题，最主要的问题是必须使用单例方式，这样就不能在服务中获取上下文，如果需要使用上下文就必须从Controller中传入。
另外就是关于事件监听器的注册和解除逻辑比较麻烦。

[czy88840616]

目的是啥？解循环依赖？

[ghostoy]

不需要通过手动注入依赖的方式来实现代码逻辑。

比如ServiceA在更新某个表时，ServiceB和ServiceC都需要执行各自的逻辑。

@Provide()
class ServiceA {
  @Inject()
  serviceB: ServiceB;

  @Inject()
  serviceC: ServiceC;

  makeUpdate() {
    // ...业务逻辑
    this.serviceB.handleUpdate();
    this.serviceC.handleUpdate();
  }
}

@Provide()
class ServiceB {
  // 当ServiceB不再关心这个操作时，不仅要删除这里的handleUpdate，还要去ServiceA中删除serviceB.handleUpdate()调用逻辑。
  handleUpdate() {}
}

@Provide()
class ServiceC {
  handleUpdate() {}
}

@Provide()
class ServiceD {
  // 当ServiceD需要关心ServiceA的更新操作时，必须去ServiceA中注入ServiceD，并调用handleUpdate才行
  handleUpdate() {}
}

这种情况下，对于ServiceA来说它并不需要关心有多少其他的Service对这个更新操作感兴趣，通过事件驱动的模式，ServiceA只要抛出事件，其他的Service只要监听事件，就可以完成这个逻辑。

@Provide()
class ServiceA {
  @Inject()
  eventEmitter: EventEmitter;

  makeUpdate() {
    this.eventEmitter.emit('a:update');
  }
}


@Provide()
class ServiceB {
  // 当ServiceB不再关心这个操作时，只要删除这里的handleUpdate
  @Event('a:update')
  handleUpdate() {}
}

@Provide()
class ServiceC {
  @Event('a:update')
  handleUpdate() {}
}

@Provide()
class ServiceD {
  // 当ServiceD需要关心ServiceA的更新操作时，只要增加监听此事件即可
  @Event('a:update')
  handleUpdate() {}
}

[waitingsong]

用消息队列行不行呢

[ghostoy]

消息队列实际上还是一种耦合的，processor里需要显式地注入需要关注的服务。另外，消息队列更重，对于一些业务逻辑来说没有必要额外启动一个队列来完成。

[czy88840616]

类似 pub/sub 的机制，可以弱化一些依赖关系。