Design Question on when to save

I was just after peoples opinion on when the best time to save an object (or collection of objects) is. I appreciate that it can be completely dependent on the situation that you are in but here is my situation.

I have a collection of objects "MyCollection" in a grid. You can open each object "MyObject" in an editor dialogue by double clicking on the grid. Selecting "Cancel" on the dialogue will back out any changes you have made, but should selecting "ok" commit those changes back to the database, or should they commit the changes on that object back to the collection and h开发者_如何转开发ave a save method that iterates through the collection and saves all changed objects?

If i have an object "MyParentObject", that contains a collection of childen "MyChildObjectCollection", none of the changes made to each "MyChildObject" would be commited to the database until the "MyParentObject" was saved - this makes sense. However in my current situation, none of the objects in the collection are linked, therefore should the "Ok" on the dialogue commit the changes to the database?

Appreciate any opinions on this.

Thanks

Generally it should save when the user thinks it is saving. In this case, yes, OK should save the objects. While I'm sure there are exceptions, I've never run into a situation where a user expected something not to be permanent once they clicked "OK", unless you also have a separate save button elsewhere on the same screen.

It really depends on your and the users needs, but as a user I would assume that it will be persisted. To make everything much more easier for the user (and more complicated for you) you should provide an undo functionality.

If the lower level dialog does the saving, I'd give it OK / Cancel buttons and just have a Close button on the higher level one (with additions / deletions being applied + saved as they're done), otherwise OK / Cancel buttons on both levels would be my preferred approach - with a cancel at either level 'doing the right thing'.

I've always been an advocate of the "dumb presentation layer" approach; So you'd have a Thing class that is editable in a ThingEditor - the ThingEditor merely reports whether the end user selected accept or cancel - the opening presentation object can make the decision as to when to persist or not. By having a dumb editor, differing consumers of the editor can use it in different ways, so...

Along these lines (and to agree with Karussel's answer) I would say that editing a topmost object (even if it is in a collection) is typically when an end user/customer might expect the save to be committed, so do it then; But for when you're editing sub objects in collections, I'd not persist those changes until the parent is requested to be persisted.