Object Transaction / Class Transaction Undo Without Database

[GoogleEyeJoe]

Dear ladies and gents,

I'm trying to determine whether the .NET Framework implements a means
of transactional processing without the need for a database.
Essentially, I'd like to enlist light-weight portable business objects
within transactions so that that have the ability to roll-back if the
client of the object wishes to undo any changes made. For example, if I
had a, let's say for sake of simplicity, a person class that had two
public properties, Forename and Surname. If the user changes both
Forename and Surname then wishes to cancel those changes (meaning that
the object will return to it's original state (before the user modified
the object by means of either of the properties)) they could do by
invoking a method (such as 'Undo').

E.g.

Original values (before user interaction)
=============== =============
personInstance. Forename is equal to "Joe"
personInstance. Surname is equal to "Bloggs" (surprise, surprise, I bet
no one saw that coming)...
Then the user modifies the Forename and Surname...
=============== =============== ===========
personInstance. Forename = "John";
personInstance. Surname = "Smith";
The user then realises that the modifications he/she/it made needs to
be undone, for whatever reason...

The user could then invoke a method such as ...

personInstance. Undo();

The object would then undo all changes made so that all data would
reflect the the object state before the user modified it.
Data after undo...
=============
personInstance. Forename is equal to "Joe"
personInstance. Surname is equal to "Bloggs" (surprise, surprise, I bet
no one saw that coming)...
My current intention is to create deep copies of the object and pass
copies to the clients, let them update the copies and if all is well
(i.e. an undo is not required) then the copy of the object would then
replace the original. Otherwise, the copy object would be discarded
(effectively appearing as an undo operation)...
Please would a kind person, or not so kind (if that is how you prefer
to be perceived) offer some light on whether transactions can be used
quickly and easily to achieve the abovementioned task, or whether my
approach is a bad/good approach/whether there is a better and simpler
way.
Many thanks for taking the time to read this.
Have a nice day,

Craig.

[samuelhon]

Hi Craig

You might want to have a look at this:
http://www.dofactory.com/Patterns/PatternMemento.aspx

Its a simple undo pattern.

Sam

[sloan]

I concur. The Memento Pattern is the way to go for "Undo's".
"samuelhon" <sa****@gmail.c omwrote in message
news:11******** **************@ h48g2000cwc.goo glegroups.com.. .

Hi Craig

You might want to have a look at this:
http://www.dofactory.com/Patterns/PatternMemento.aspx

Its a simple undo pattern.

Sam

[Dave Sexton]

Hi Craig,

You can use COM+ services in managed code for transaction support just like
you always have in COM.

ServicedCompone nt on MSDN:
http://msdn2.microsoft.com/en-us/lib...component.aspx

In the 2.0 framework there is a new namespace as well:

System.Transact ions

It contains managed classes that provide transaction processing support for
local and distributed transactions. For instance, you can use the
TransactionScop e class to enlist a System.Data.IDb Connection into a managed
transaction without explicitly using an implementation of IDbTransaction.

TransactionScop e class on MSDN:
http://msdn2.microsoft.com/en-us/lib...tionscope.aspx

Using transactions along with commands (or mementos as another respondant
suggested) can make undo/redo operations transparent in code by encapsulating
the commit/rollback logic in separate components.

You can create a singleton in your application that will allow any caller to
undo the last operation, redo the previous operation or cancel the current
operation all by storing a current operation context. In my applications I
use a stack to implement the undo/redo context.

--
Dave Sexton

"GoogleEyeJ oe" <cr*****@hotmai l.comwrote in message
news:11******** **************@ i3g2000cwc.goog legroups.com...

Dear ladies and gents,

I'm trying to determine whether the .NET Framework implements a means
of transactional processing without the need for a database.
Essentially, I'd like to enlist light-weight portable business objects
within transactions so that that have the ability to roll-back if the
client of the object wishes to undo any changes made. For example, if I
had a, let's say for sake of simplicity, a person class that had two
public properties, Forename and Surname. If the user changes both
Forename and Surname then wishes to cancel those changes (meaning that
the object will return to it's original state (before the user modified
the object by means of either of the properties)) they could do by
invoking a method (such as 'Undo').

E.g.

Original values (before user interaction)
=============== =============
personInstance. Forename is equal to "Joe"
personInstance. Surname is equal to "Bloggs" (surprise, surprise, I bet
no one saw that coming)...
Then the user modifies the Forename and Surname...
=============== =============== ===========
personInstance. Forename = "John";
personInstance. Surname = "Smith";
The user then realises that the modifications he/she/it made needs to
be undone, for whatever reason...

The user could then invoke a method such as ...

personInstance. Undo();

The object would then undo all changes made so that all data would
reflect the the object state before the user modified it.
Data after undo...
=============
personInstance. Forename is equal to "Joe"
personInstance. Surname is equal to "Bloggs" (surprise, surprise, I bet
no one saw that coming)...
My current intention is to create deep copies of the object and pass
copies to the clients, let them update the copies and if all is well
(i.e. an undo is not required) then the copy of the object would then
replace the original. Otherwise, the copy object would be discarded
(effectively appearing as an undo operation)...
Please would a kind person, or not so kind (if that is how you prefer
to be perceived) offer some light on whether transactions can be used
quickly and easily to achieve the abovementioned task, or whether my
approach is a bad/good approach/whether there is a better and simpler
way.
Many thanks for taking the time to read this.
Have a nice day,

Craig.