mORMot Open Source

radexpol

Member

From: Poland, Krk

Registered: 2019-11-29

Posts: 116

Multiple callback events

What is the preferred solution for multiple event triggering engine from server to client. For example:

type
  TSubscribe = class(TInterfacedObject, ISubscribe)
  protected
    WorkingHoursListeners: array of IWorkingHoursChanged;
    ConfigurationChangeListeners: array of IConfigurationChanged;

    procedure WorkingHoursChange(const callback: IWorkingHoursChanged);
    procedure ConfigurationChange(const callback: IConfigurationChanged);

    procedure CallbackReleased(const callback: IInvokable; const interfaceName: RawUTF8);
  public
    procedure RaiseWorkingHoursChange(const QueueID: Integer; const HourFrom, HourTo: TDateTime);
    procedure RaiseConfigurationChange(const Key, Value: string);
  end;

or create separate class for each event like:

type
  TWorkingHours = class(TInterfacedObject, IWorkingHours)
  protected
    Listeners: array of IWorkingHoursChanged;
    procedure WorkingHoursChange(const callback: IWorkingHoursChanged);
  public
    procedure RaiseChange(const QueueID: Integer; const HourFrom, HourTo: TDateTime);
  end;

and the same for ConfigurationChange. I have to implement about 100 different callbacks.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,238

Website

Re: Multiple callback events

The Interface Segregation SOLID principle prefer multiple interfaces.
But one interface per event is not a good idea either.
So I would try to group the events per dozen, into a dozen of classes, separated by bounded context (in DDD terms).

Notes:

If you have 100 different events to track, I would not create 100 different callbacks, but a dozen callbacks, depending on the context, and using a dedicated DTO class to send the changes.
At least I would define the kind of events as enumerate, then put some shared fields (like timestamp, description text), and the main potential  values (from ORM perhaps).
It may help creating a TSQLRecord of events on Disk, very useful as AuditTrail.

If you want to keep 100 separate callbacks, I would use an array of the enumerate to keep all the registered the callbacks on server side.

protected
  Subscribed: array[TWorkEvent] of IInvokable;

It would help reduce the code, using some wrapper methods.
Then a regular Publish/Subscribe method should be enough.

radexpol

Member

From: Poland, Krk

Registered: 2019-11-29

Posts: 116

Re: Multiple callback events

OK, thank you. I asked about events performance in other forum thread, can you look at my questions?