Laden...

Änderungen nachverfolgbar machen

Erstellt von pinki vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.248 Views
pinki Themenstarter:in
709 Beiträge seit 2008
vor 6 Jahren
Änderungen nachverfolgbar machen

Hallo zusammen,

ich möchte eine Anwendung (Angular als Frontend und ASP.NET Core 2 als Backend) schreiben.
Als DBMS kommt MSSQL zum Einsatz.

Was ich gern hätte: Jede Änderung soll nachverfolgbar sein.

Ich habe mich bereits etwas umgesehen und folgende Möglichkeiten stachen dabei heraus.

Möglichkeit 1: Nach jeder Änderung den kompletten Datensatz neu speichern inkl. Änderungszeitpunkt und der ID des Benutzers, der die Änderung vorgenommen hat.
Möglichkeit 2: Event Sourcing.

Möglichkeit 2 klingt für mich am interessantesten, allerdings habe ich hier noch keinerlei Erfahrungen.

Nun zu meiner Frage: Wie sollte man das am besten angehen?

Gruß

pinki

2.298 Beiträge seit 2010
vor 6 Jahren

Hat jetzt nichts mit EventSourcing zu tun, aber wir handhaben soetwas meist derart dass es eine "History"-Tabelle gibt, in die die vorhergehenden Einträge übernommen werden.

Soll also ein bestehender Eintrag in TabelleX per Update geändert werden, wird der bisherige Eintrag in die TabelleXHistory übertragen. Nach n-Tagen werden Einträge aus der History dann gelöscht.

Moment, wenn ich Event Sourcing korrekt verstanden habe, ist es ja quasi genau das...

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

pinki Themenstarter:in
709 Beiträge seit 2008
vor 6 Jahren

Danke für deine Antwort.
Für mich sieht das eher nach Möglichkeit 1 in etwas anders aus.

Wenn ich Event Sourcing richtig verstanden habe, werden da in einer Art Log nur die Änderungen gespeichert. Möchte man den aktuellen Zustand eines Objekts haben, wird dieses anhand des Logs rekonstruiert. Für bessere Performance gibt es dann Snapshots, damit man nicht immer das ganze Log durchlaufen muss. Gelöscht wird nie irgendetwas.

In der Theorie klingt das für mich total einfach. Bei der Umsetzung habe ich aber ein gewaltiges Brett vorm Kopf.

2.298 Beiträge seit 2010
vor 6 Jahren

Möchte man den aktuellen Zustand eines Objekts haben, wird dieses anhand des Logs rekonstruiert. Für bessere Performance gibt es dann Snapshots, damit man nicht immer das ganze Log durchlaufen muss. Gelöscht wird nie irgendetwas.

Was ich aus der Beschreibung lese, geht es nicht um den aktuellen Zustand des Objektes, sondern der Nachverfolgbarkeit / Nachstellbarkeit, wie das Objekt in den aktuellen Zustand kam. - Das heißt, der aktuelle Zustand wird nach wie vor komplett gespeichert und zusätzlich quasi die Änderungen die durchgeführt wurden. Daraus schließe ich, das von mir beschriebener Ansatz (abzüglich der Löschung) eine einfache Implementierung des Prinzips ist.

EDIT: Die vollständige Implementierung würde natürlich nicht einfach in einer History-Tabelle münden. - Vollständig würde dann eher etwas gespeichert werden wie "Änderung Objekt X an folgenden Stellen".

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

pinki Themenstarter:in
709 Beiträge seit 2008
vor 6 Jahren

Vollständig würde dann eher etwas gespeichert werden wie "Änderung Objekt X an folgenden Stellen".

Wie würde man sowas denn modellieren?

M
33 Beiträge seit 2012
vor 6 Jahren

@pinki
Willst du denn die Veränderung nur sehen oder ggf. auch wieder rückgängig machen ?!?

Falls fallend du vom Dach verschwandest, brems bevor du Unten landest.

2.298 Beiträge seit 2010
vor 6 Jahren

Habe ich das Prinzip jetzt komplett verstanden dann durch Kommandos deren Ausführung persistiert wird.

Wird nun ein Kommando ausgeführt, wird in Form einer Zeichenkette z.B. bei Änderung einer Property eines Objektes der alte und der neue Wert gespeichert. Meinetwegen in Textform: "Änderung Nachname von Muster nach Müller".

Je nach Komplexität des Systems kannst du im einfachsten Fall eine Tabelle verwenden die irgend eine Verbindung auf das eigentliche Objekt und die letzte Änderung besitzt.

Meinetwegen:
TargetType | TargetID | Command
Device | 1 | Changed device state from off to on
User | 435 | Changed users lastname from Muster to Müller

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

pinki Themenstarter:in
709 Beiträge seit 2008
vor 6 Jahren

@MrWasabi
Ich würde die Änderungen auch gern wieder rückgängig machen können.

16.806 Beiträge seit 2008
vor 6 Jahren

Event Sourcing ist eine prinzipielle Kommunikations- und Workflow-Strategie.
Es bringt von Haus aus aber keine spezifischen Features wie Undo und dessen Teile mit.

Hier geht es vor allem um die Nachvollziehbarkeit der Plattform durch Events und Operationen; nicht von Domänenobjekten oder Entitäten.

M
33 Beiträge seit 2012
vor 6 Jahren

Natürlich kommt das ein bisschen auf die Komplexität der Daten an aber ich würde
vorerst eine "einfache" Lösung anstreben.

z.B. das original Objekt Serialisieren und ablegen z.b. als JSON


public class ObjectDump
    {
        public int Id { get; set; }
        public int UserId { get; set; }
        public DateTime DumpTime { get; set; }
        public int ObjectKey { get; set; }
        public string ObjectTypeName { get; set; }
        public string ObjectJsonDump { get; set; }
    }

Dann könntest du später via Reflection die Änderungen nachvollziehen
und ggf. Teile des Objects oder das ganze Object wieder herstellen.

Natürlich kenne ich den Umfang deiner Daten und auch die Performance-Anforderung nicht 😃

Falls fallend du vom Dach verschwandest, brems bevor du Unten landest.

pinki Themenstarter:in
709 Beiträge seit 2008
vor 6 Jahren

Den Umfang der Daten und die Performanceanforderungen kenne ich aktuell selbst noch nicht.
Da wird gerade spezifiziert.

Ist ObjectKey die ID des Objekts aus dem Dump innerhalb der eigenen Tabelle?

2.298 Beiträge seit 2010
vor 6 Jahren

Hallo,

ich denke dass die hier beschriebenen Informationen eigentlich eine gute Basis liefern um ein brauchbares System zu modellieren.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

M
33 Beiträge seit 2012
vor 6 Jahren

Ja das sollte die ID des Objekts sein damit du nicht die JSON-Daten nach der ID durchsuchen musst.

Falls fallend du vom Dach verschwandest, brems bevor du Unten landest.