C# Wie hieß das Interface für "Resettable"-Klassen?

[Physikbuddha]

Moin zusammen,

helft mir mal kurz bitte auf die Sprünge.
Ich hatte irgendwann mal ein Interface (oder abstrakte Klasse) gesehen, um schwebende Änderungen in einer Modell-Klasse zu realisieren.

Also der Klassiker: Man hat ein Modell, das 1:1 eine Tabelle in der Datenbank realisiert.
Jetzt kann ich Änderungen an den Properties vornehmen, aber möchte die nicht sofort persistieren, falls der Nutzer den Vorgang abbricht.
Dafür gibts dann entweder die Methode Persist() oder Commit() zum Wegschreiben, oder aber eine Methode Revert() oder Reset(), die die Änderungen verwirft und das Element neu aus der Datenbank lädt.

Jetzt komm ich aber beim besten Willen nicht mehr auf den Namen.
Suche hat auch nicht so viel ergeben.
Habt ihr ne Idee? Kann auch sein, dass das Interface auch nur bei WPF mitkam und für ViewModels gedacht war.

Klar kann ich das auch selber easy bauen, aber ich möchte das Rad nicht unbedingt nochmal neu erfinden wollen.

Gruß vom Physikbuddha

 

[Bunhy]

Ich arbeite beruflich mit .NET und WPF und so ein Standard-Interface, wie Du es ansprichst, ist mir nicht bekannt. Kam es möglicherweise aus einem Framework oder Lib? Denn dann kann es dir vermutlich niemand mit Sicherheit beantworten, weil es darauf ankommt, was Du da damals gefunden/genutzt hast.

Im Übrigen: Wichtiger wäre wohl die konkrete Implementierung wiederzufinden oder? Das Interface anzulegen ist doch nun wirklich kein Neuerfinden des Rades, wenn Du es anschließend ohnehin ausimplementieren musst

 

[Physikbuddha]

Ja schon, nenn mich halt penibel, aber halte mich gerne an vorhandene Sachen.

Alleine schon, dass ich mir dann keine eigene Namen ausdenken muss – ist jetzt ICommitable oder IResettable besser? Oder doch vielleicht etwas mit ...Model... im Namen, damit es klarer ist?
Stell ich mir halt ungern.

 

[TheCadillacMan]

Kann es sein, dass du das Active Record Pattern suchst?
Das .NET-Interface aus deiner Erinnerung ist vermutlich IEditableObject.

 

[Physikbuddha]

Hmm, habe ich so noch nicht gehört.
Das einzige, was ich noch gefunden habe, waren Implementationen mit IsDirty.

Ich gehe jetzt einfach mal davon aus, dass ich das geträumt habe. War bestimmt wirklich mal in irgendeinem Framework enthalten. LINQ-to-SQL bietet mit Object States ja so etwas in der Richtung an.

Ist ja auch eine Antwort auf meine Frage. Dann schreib ich das halt schnell selbst. Wenn ich viel Lust und Laune hab, mach ich mir mein eigenes Paket für später draus.

Danke euch.

 

[TheCadillacMan]

LINQ-to-SQL bietet mit Object States ja so etwas in der Richtung an.

Praktisch alle ORMs haben Change Tracking in irgendeiner Form. Als separate Library für beliebige Objekte hab ich das aber noch nicht gesehen.

 

[new Account()]

Eventuell ist aus STM.NET etwas geworden oder es gibt ähnliches ...

Edit: STM.NET ist eingestampft worden. Wikipedia listet jedoch Alternativen: https://en.wikipedia.org/wiki/Software_transactional_memory#C#

 

[benneq]

Ich würde sowas nicht über ein Interface lösen, sondern über eine externe Klasse / Funktion. Denn diese Funktionalität hat ja nicht wirklich was mit der (Business) Logik der Objekte zu tun, oder? Ausnahme: Die Logik im Objekt erfordert, dass es sich selbst zurücksetzen kann. Aber selbst diesen Fall könnte man (wahrscheinlich etwas umständlich) über eine externe Funktion abbilden.

Also lieber irgendwo eine statische Funktion hinstellen, die Objekte klont. Meinetwegen passend dazu dann noch eine eigene Klasse, die den Klon und das eigentliche Objekt verwaltet und zurücksetzen kann. Ist aber wahrscheinlich in 99% der Fälle schon als "Overengineering" zu bezeichnen.

Und dann müsstest du natürlich auch noch wissen, ob du wirklich nur das Objekt selbst klonen willst, oder ob du eine Deep Copy erstellen willst (also so, dass auch alle darin enthaltenen Objekte kopiert werden). Oder vielleicht nur ein Teil davon.

 

[new Account()]

Statt der Klonerei würde ich lieber das Memento-Pattern umsetzen

 

[Bunhy]

Ja schon, nenn mich halt penibel, aber halte mich gerne an vorhandene Sachen.

Spricht ja auch nichts dagegen, nur scheint es das nicht zu geben. Und wahllos irgendwas zu referenzieren, nur um eine Schnittstelle davon zu bekommen, halt ich für ungleich nachteiliger.

Von statischen Dingen dafür, wie oben vorgeschlagen, würde ich grundsätzlich erst Recht die Finger lassen, wenn Du Wert auf testbaren und architektonisch sauberen Code wert legst. Dann lieber das Pattern, falls es deinem Einsatzzweck dient.

 

[benneq]

Statt der Klonerei würde ich lieber das Memento-Pattern umsetzen

Meinetwegen auch das Hauptsache nicht die Business Logik mit nicht-business-logik-relevanten Dingen verschandeln.