UI or BO responsible for managing EditLevel?

ajj3085 posted on Tuesday, October 13, 2009

Hi,

I have a use case where a BO must be able to duplicate itself. Similar to clone, but the user is left with a new instance with a copy of most of the data already filled in.

I am having a problem on a form where I switched to BindingSourceNode to manage the BindingSources for the root and child objects.

Where this is a problem is that I used to have code in the Duplicate method of the BO which did a Clone, then called ApplyEdit on the clone. I guess this used to work, but no longer does (the child objects have a EditLevel of 2, and the root now has an edit level of 1 after the apply edit... previously I suppose it was all 0, because it was all working).

So I was looking at fixing the code, but now I'm questioning whether or not the BO should be responsible for fixing the edit level, or if the UI should do it.

I would think the UI should be responsible for this by unbinding and applying edit before the duplicate, but I'd just like a reality check. Is that the right way to go? I'm not worried about the user not being able to hit cancel in any of the grids because a new window will be opening anyway.

Thanks
Andy

RockfordLhotka replied on Tuesday, October 13, 2009

I suspect the only answer is to safely unbind the object from the UI (so editlevels are all 0), then do the clone, then rebind.

Remember that Clone() is a real clone - warts and all - of the object as it is when cloned.

ajj3085 replied on Tuesday, October 13, 2009

That's what I thought. I'll remove the appy edit from the BO's duplicate and do the work in the UI.

Thanks!