Hi Guys,
My apologies for the long lead in here, but I think it helps you understand my problem. I am developing a system that works as follows:
The user selects from a list of choices.
Depending on his choice the UI is reconfigured, static variables are set, etc...
Once the user has finished with his choice, he wants to select another.
The code must "undo" all the UI changes, etc... and apply the correct changes for his new choice
Now, if he has three choices its obvious what to do (do it the hard way). But what if he had 25 choices? And we want to add choices every few months?
Thus it logically follows that if choice A is selected, then B is selected; then the code for "choice A" must "rollback" all its changes and leave the application in its original state. Then the code can apply choice B.
Now, a very simple way to solve this problem is to have a class that fires off an event when the transaction is canceled. Once the event fires "choice A" must rollback all its changes. We could even do this through an interface (i.e. have a Rollback() method for "choice A").
Thats over simplifying the problem, because its very hard to code a single block of code that does a "rollback" for all the possible changes made by a big module. What if the module calls a custom library? how will it know how to undo the changes made by the library?
An alternative is, each time a major change is made in the module it registers a "rollback" delegate with the transaction class. When the transaction class needs to do a "rollback", it simply runs all the individual "rollback" delegates that have been registered with it.
The problem with that is you have a class with references to various large objects (forms, etc..) so that when "rollback" is called it can make the changes it needs to. So on a long running transaction, your forms are sitting in memory longer than they need to.
So, does anyone have a better pattern than my multiple rollback methods? or do you have a way to "fix" my multiple rollback pattern?
Cheers
Paul