Why is it recommended to unbind bussiness object before save operation?

Why is it recommended to unbind bussiness object before save operation?

Old forum URL: forums.lhotka.net/forums/t/12079.aspx


sash_kr posted on Friday, July 19, 2013

I have WinForms application.

Some save operations may take few seconds. Usually, while saving is in progress, I'm blocking (Enable = false) main Panel control which contain all binded controls (TextBox, Combobox etc.) and unblock it when save is done. I don't unbind datasource, so I see my values on controls. And that's what I like.

But when we set DataSource to null (before save) - all my controls are empty until save operation complete. That is what I don't like.



So why it's suggested to unbind?

JonnyBee replied on Saturday, July 20, 2013

Hi,

Several reasons:

So for async operations in WinForms I usually prefer:

sash_kr replied on Saturday, July 20, 2013

"when an edit operation is active you have at least one snapshot of the object (and children) in memory and you do NOT want to include these over the wire."

Can you explain it more detailed? I could not understand.

"when an edit operation is active you cannot be sure if the user has changes in the UI component only that is not updated in the business object yet."

 Maybe I didn't understand you again, but didn't bindingSource.EndEdit() method save UI component value to datasource? Because I don't have a problem with that.

"So for async operations in WinForms I usually prefer:"

 Well, I like your method too Yes. Thanks.

 

P.S.

Forgive me for maybe stupid questions. I'm not a newbee at all. But CSLA is big framework and the only documentations that we have are "CSLA" books from Rockford. Which contain tips that are not suitable for me. And not always I can understand is it the only way or maybe we have another way.

 

 

 

JonnyBee replied on Saturday, July 20, 2013

Windows Forms databinding use the IEditableObject interface to call BeginEdit/CancelEdit/EndEdit and there is quite strict rules to follow. 

F.ex BeginEdit may be called many times but only the first call through the interface should be honored. 
See: http://msdn.microsoft.com/en-us/library/system.componentmodel.ieditableobject.beginedit.aspx  

This method is typically used to capture the BeginEdit semantics of a DataRowView.

If BeginEdit is called on an object that is already being edited, the second and subsequent calls are ignored.

 

Notes to Implementers

An object implementing this interface needs to store updates after BeginEdit in such a way that they can be discarded if CancelEdit is called.

Add to this that the N-level undo mechanism extends this behaviour in such a way that you can take a complete snapshot before you attach the object to databinding and you MUST unbind the object before you can call CancelEdit/ApplyEdit on the corresponding BeginEdit call!!! 
IE: CSLA has different behavior depending on whether you call BeginEdit directly on the object or through the IEditableObject interface. For as long as the object  has an active BeginEdit through the IEditableObject interface any more calls to BeginEdit will NOT be honored/have any impact.

Take f.ex that you use N-Level undo - then you must first 

sash_kr replied on Sunday, July 21, 2013

Honestly, I didn't understandConfused.

Let's take an example:

this.invoice = Invoice.GetInvoice(653);
this.bindingSource1.DataSource = this.invoice;

// State of our invoice BO:
//    EditLevel = 1

...

...

Then  in "OnClick" handler we do this:

this.bindingSource.EndEdit();

// State of our invoice BO:
//    EditLevel = 0

this.invoice =  await this.invoice.SaveAsync();
this.bindingSource1.DataSource = this.invoice;

 

So, what is wrong with this example?

 

sash_kr replied on Tuesday, July 23, 2013

OK, forget! I think that everything is fine with my example. Unbind is unnecessary in that situation. I just can't understand why you make the things so complicated? (taking snapshot before binding (BusinessBase.BeginEdit), than after databinding (IEditableObject.BeginEdit), then call IEditableObject.EndEdit and at the end unbind it and call CancelEdit/ApplyEdit).

ajj3085 replied on Tuesday, July 23, 2013

sash_kr

OK, forget! I think that everything is fine with my example. Unbind is unnecessary in that situation. I just can't understand why you make the things so complicated? (taking snapshot before binding (BusinessBase.BeginEdit), than after databinding (IEditableObject.BeginEdit), then call IEditableObject.EndEdit and at the end unbind it and call CancelEdit/ApplyEdit).

 

The snapshots taken on BeginEdit and removed during cancel or apply are to support n-level undo.  Think about in SSMS if  you edit a table row using the graphical editor, the row header gets a pencil icon, and as long as you don't click out of the row, you can hit ESC to cancel your data changes and leave the row unchanged.  That's the behavior Csla is implementing for you.

Copyright (c) Marimer LLC