Ja sorry, du hast natürlich recht. Da habe ich mich vertran. Der Service soll auch nicht direkt mit der Datenbank sprechen. Die Kommuniaktion geht nur über die
API. Aber irgendwie muss ich es realisieren, dass der Service prüft (ping o.ä.), ob die Datenbank erreichbar ist. Mehr soll der Service nicht mit der
DB direkt machen. Das könnte man ja auch über einen
API-Aufruf prüfen - da fällt der Ping weg, der ohnehin nichts darüber aussagt, ob die
DB funktioniert/erreichbar ist.
Hört sich ja schon besser an, allerdings ist das Benachrichtigungs-System wie du das skizzierst hast etwas ... seltsam.
Wenn du die Nachrichten jetzt pro Modul sendest, dann zieht ja jedes neues Modul eine Änderung in der Nachrichten-Struktur mit sich. Da wäre es doch besser, einfach Nachrichten zu schicken, wenn sich die Daten geändert haben. Das Modul selber bekommt dann diese Information mit, und entscheiden ob es damit etwas zu tun hat oder nicht. Hat es, dann lädt es die betroffenen Daten neu, wenn ich, dann eben einfach nicht.
Erweiterst du jetzt die Module, dann brauchst du das in der Benachrichtigung nicht zu berücksichtigen, denn die Module bekommen das schon mitgeteilt.
Zudem würde ich diese Benachrichtigungen sowieso an die Zugriffs-Interfaces verteilen, wo ich dann jeder den es interessiert registrieren kann.
Delphi-Quellcode:
TDataChangedEventArgs = class( TEventArgs )
property Action : TDataAction read FAction; // Added, Changed, Removed
property DataId : TDataId read FDataId;
end;
TDataChangeEventHandler = reference to procedure( const Sender : TObject; e : TDataChangedEventArgs );
IMyRepository = interface
procedure Get( DataId : TDataId; out Data : TData );
property DataChanged : IEvent<TDataChangedEventArgs>;
end;
An den
DataChanged
Event kann sich jeder dranhängen, der das wissen muss und entsprechend reagieren. Das Repository kümmert sich um den Empfang der Nachricht und verteilt diese. Schon können auch neu erstellte Module einfach so auf diese Nachrichten reagieren.