There are different scenarios:
Scenarios 1, 2 and 5 are all pretty similar - you explicitly call the object's n-level undo methods:
Customer cust = Customer.GetCustomer(123);
cust.BeginEdit();
// interact with cust
cust.ApplyEdit(); // or cust.CancelEdit();
cust = cust.Save(); // unless you did a CancelEdit() of course
Scenarios 3 and 4 are covered in the Using CSLA .NET 3.0 ebook, and are not trivial. This is because data binding directly interacts with the object's undo features, and Windows Forms has a lot of very specfiic rules YOU MUST FOLLOW or it won't work right.
The new CslaActionExtender in version 3.6 should help simplify some aspects of scenarios 3 and 4.
Scenario 6 may be the simplest of the bunch, because you just set the ManageObjectLifetime property of the CslaDataProvider to True and let the CslaDataProvider (and WPF commanding) do nearly all the work.
In any case, the ProjectTracker reference app is the place to look for examples of all interface types.
The undo feature of CSLA doesn’t work (easily) at that
level of granularity. It doesn’t record specific changes – it just
takes a snapshot of the object graph’s state at a point in time, and
reverts to that point.
So to do what you describe:
x.BeginEdit()
x.Description = “help”
x.BeginEdit()
x.Description = “I’m stuck”
x.CancelEdit()
Print x.Description
> “help”
x.CancelEdit()
Print x.Description
> “”
There is no redo supported by CSLA, so 5 and 6 won’t happen.
And really, BeginEdit() is an expensive operation – it isn’t
something you want to do to trap a single field change – it is designed
to work at the object graph level.
Rocky
Copyright (c) Marimer LLC