You have a form that has an object injected into it. The user interacts with the form and updates the injected object via the UI. If the user then ‘Cancels’ the form, whose responsibility is it to undo those changes?
Should the form have created a clone of the object passed in, and return that to the client? Or should the client watch for the ‘Cancel’ action and perform the undo action?
Is there a ‘best practice’ for this?
0
Ideally, the UI shouldn’t know about your business objects directly. It should know what it has to display and where to send any submission. The receiver of the submission should know how to process that submitted data with respect to your domain objects.
Thus there should be nothing to roll back, only form data to be discarded.
Sometimes you have to store form data somewhere, in case the submission is put on hold, or the application crashes, or whatever. In those cases, I would still suggest storing form data separately from domain data, making it just as easy to discard.
In the rare occasion where you might need to apply data changes and test it before rolling it back. If you absolutely can’t use a staging area then use soft-deleting and history records, but definitely don’t expose that to the UI. Only allow it to switch between revisions.
3
If I am following correctly, you have clicked the save button, but then want the ability to discard those changes almost straight away.
There is a further complication here which may be that before hitting the cancel button, the user might make another change and hit Save.
So it could be the case that you store a history of the object in the database, track a “last version ID” and use that on Cancel postback to restore the last version.
2