Best practice for saving objects owned by objects

  • Thread starter Thread starter BobRoyAce
  • Start date Start date
B

BobRoyAce

Let's say that I have a class called Customer and a class called
CustomerAddress.

Now, further suppose that the Customer class has a property called
_CustomerAddresses, which is List(Of CustomerAddress).

Now, there's a form to edit a Customer, on which the user can click on
a SAVE button to save changes, or on a CANCEL button to cancel any
changes that they have made. In addition, on the Customer form, the
user can make changes to the different CustomerAddress's that belong
to the Customer (i.e. add, edit, remove). A separate form is used for
adding or editing a CustomerAddress. For example, the user could
select a CustomerAddress, in a grid, and then click on an EDIT button,
at which point the Customer Address form is shown modally. On the
Customer Address form, the user can also click on SAVE or CANCEL.

Now, here's where the question comes in. The way that I am
implementing this is that, if the user clicks on CANCEL for the
Customer, any adds, edits, or deletes of CustomerAddress records
associated with that Customer are disregarded/discarded.

Is this the "usual" way to implement functionality like this?
 
BobRoyAce said:
Let's say that I have a class called Customer and a class called
CustomerAddress.

Now, further suppose that the Customer class has a property called
_CustomerAddresses, which is List(Of CustomerAddress).

Now, there's a form to edit a Customer, on which the user can click on
a SAVE button to save changes, or on a CANCEL button to cancel any
changes that they have made. In addition, on the Customer form, the
user can make changes to the different CustomerAddress's that belong
to the Customer (i.e. add, edit, remove). A separate form is used for
adding or editing a CustomerAddress. For example, the user could
select a CustomerAddress, in a grid, and then click on an EDIT button,
at which point the Customer Address form is shown modally. On the
Customer Address form, the user can also click on SAVE or CANCEL.
Click to expand...

At that point the object should be marked as Dirty and the Save button only
enabled if the user has made a change to the object. If the object has
changed (marked as dirty), then the Cancel should return the object to its
state prior to it being edited. This is on the edit of an existing object
pulled from a database, existing data.
Now, here's where the question comes in. The way that I am
implementing this is that, if the user clicks on CANCEL for the
Customer, any adds, edits, or deletes of CustomerAddress records
associated with that Customer are disregarded/discarded.

Is this the "usual" way to implement functionality like this?
Click to expand...

If the user uses the Cancel for the parent object, then the screen should be
exited cancelling all changes to the parent and its child objects. The
cancel will have taken place if you force the user to the selection screen
and make the user select the parent object again which selects its child
objects again for possible editing.

If the child object is being inserted and you want to cancel the insert of
the object, you simply mark it as not Dirty on its Save out of the screen.

If you want to know how to do this properly, then may I suggest you get one
of the books in the link. You read the book, you put the CSLA Framework code
together, you put the Tracker project code together that uses the CSLA
Framework, and you play with the Windows Desktop version of the Tracker
project. I am not telling you to implement CSLA in any project you are
doing. But you can see and implement the concepts of object state and
manipulation by looking at CSLA.

I have used CSLA in VB6, C#.Net and used the CSLA concepts in building non
CSLA .NET in both VB and C#.Net
projects based on the CSLA concepts of building objects manually and their
manipulation in code.

http://www.lhotka.net/cslanet/download.aspx

If you do what I have suggested, then you won't go wrong, and you see
actually what you have to do and have in place.
 
Back
Top