Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

Kopie ohne ICloneable [oder warum man Objekte nicht kopieren sollte; Transaktionen auf Objekten]
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo dN!3L,
Zitat
Hm, und was sollte er stattdessen machen?
man könnte die Klassen, die transaktionierbar sind, von einem Interface ITransactionable erben lassen und das Interface dann als Parmetertyp von RegisterObject verwenden. Das wäre dann eine Compilezeitüberprüfung. Oder man zeichnet die Klassen, die transaktionierbar sind, mit einem Attribut aus, dessen Vorhandensein man zur Laufzeit prüft.

Aber das beantwortet nur die theoretische Machbarkeit. Über die Praktikabilität habe ich mir keine Gedanken gemacht.

Bei dem BusinessObject-Ansatz hat man die transktionierbaren Klassen automatisch ausgezeichnet, eben indem sie von BusinessObject erben.

herbivore
private Nachricht | Beiträge des Benutzers
yetibrain
myCSharp.de - Member

Avatar #avatar-2570.gif


Dabei seit:
Beiträge: 54

Transaktionen für transiente Objekte

beantworten | zitieren | melden

hi herbivore, Quallo, cadi u. a.

Habe mir diesen thread durchgelesen und finde die Idee sagenhaft. 8) Transaktionen für transiente Objekte. Ich finde herbivore hat vollkommen Recht, selbst wenn ein Objekt unterschiedliche Zustände hat so muss es dafür nicht zwangsläufig seine Identität verlieren indem es z. B. kopiert wird. Es hört sich zwar irgendwie logisch an dass wenn man ein Objekt zwecks Manipulation etwa in eine Dialogbox reinreicht dass man vorher eine Kopie erstellt weil der Benutzer eventuell "Cancel" anklickt um sämtliche Änderungen zu verwerfen, dann muss man natürlich den vorherigen Zustand wieder herstellen. Allerdings genügt es tatsächlich lediglich den Zustand zu sichern und nicht das komplette Objekt, ein Transaktionsmechanismus finde ich da die bessere Lösung. Es wäre wirklich schön wenn das in .NET schon enthalten wäre. =)

Seid ihr denn noch weiter gekommen bzw. was ist aus dieser Idee geworden? Das würde mich wirklich interessieren.
~~yb~~~~~~~~~~~~~~
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo yetibrain,

die einzige Neuigkeit, die sich aus meiner Sicht ergeben hat, ist die Variante von codester in "Zeiger" oder Kopie , die auch Collections berücksichtigt/behandelt.

Mich hindert so ein bisschen am Weitermachen, dass es bestimme Grenzen gibt, an die man man relativ schnell stößt und die sich auch nicht überwinden lassen, z.B. wenn man an Dateien denkt oder noch besser an Netzwerkstreams. Gesendete Daten bleiben gesendet. Ein Wiederherstellen des alten Zustands beim Rollback ist nicht möglich.

Unabhängig davon gibt es eine Bibliothek von Ralf Westphal mit Namen NSTM. Siehe dazu Mein aktuelles Steckenpferd: Software Transactional Memory und Software Transactional Memory. Im Focus dieser Bibliothek liegt zwar der gleichzeitige Zugriff durch mehrere Threads und es wird dort intern auch mit Clone gearbeitet, aber es gibt natürlich trotzdem Transaktionen mit Commit und Rollback und mindestens einen Blick ist das auf alle Fälle wert.

herbivore
private Nachricht | Beiträge des Benutzers