Hello there and excuse my ignorance/inexpertise.

I'm developing a Winforms application using C# in .net 2.0 with version 2 of llblgen pro, Self-servicing scenario.

Some of my forms are fairly complex and involve, for instance, a combination of textboxes (to allow the user to edit the base entity) and lists/gridviews (to allow the user to edit associated entities).

The users want Apply and Undo buttons on the form. This is very easy to implement where edits are made to the main entity but where lists or gridviews are changed, I'm not too sure what the best approach is. I have tried using a transaction to wrap all edits to the form but this approach seems flawed - a user might have a form open for a long time with an open transaction. In any case, I couldn't get the approach to work, even with ReadUncommitted, because of locking issues.

My question is this: what is the best way of extending the Apply/Undo functionality to the whole form such that any change the user makes can be committed or rolled back?

Thanks for reading this.

Carl White

Example

As a contrived example, consider a form on which we edit details of a Person. The form might have a group of textboxes, comboboxes, etc. The form might also have, as a silly example, a list of favourite foods, which is added to and removed from by an additional form.

Your question almost seems like a setup

Check out the section "Generated code - Unit of work and field data versioning, SelfServicing" in the documentation.

Sometimes actions on entities span a longer timeframe and / or multiple screens. It's then often impossible to start a database transaction as user-interaction during a transaction should be avoided. To track all the changes made and to persist them in one transaction can then be a tedious task. With the UnitOfWork class this can be solved. The UnitOfWork class lets you collect actions on entities or collections of entities and can perform these actions in one go.

Unit of works seem indeed what you need to keep track of your modifications. Now, there should be two ways using them:

If you don't want to have the user actions commited to the db until he saves and leave, then you should ass all entity changes to a Unit Of Work and run it by the end.

If you want the changes to be applied and keep reversible, then for every save, you should increment a UOW with the inverse action (adding the old entities for save, deleting the newly created etc...). But now that UOF will be inverted, so in the end you will need to to invert the various properties yielding UnitOfWorkElement2 to keep consistent.

Thanks very much. I'm very grateful, if slightly embarrassed for not noticing UOW in the documentation!

Carl