Hi,
My application contains multiple root objects that must be saved in a same transaction. We made a command object that make this possible.
The problem is that we must only save by using this command object. GUI must never call directly a root object save method.
We have a problem with EditableRootListBase<T> , we bind a collection that inherits from EditableRootListBase<T> and the apply edit event raised by the grid when changing grid focus make the object being saved.
I'm not sure but maybe it is related to this code that I found in EditableRootListBase<T> :
#region IParent Members
void Csla.Core.IParent.ApplyEditChild(Core.IEditableBusinessObject child)
{
if (!_activelySaving && child.EditLevel==0)
SaveItem((T)child);
}
Is there a way to avoid object being saved when grid line lost focus?
Thanks
Nothing says that good object design must use only one object for a use case. Multiple objects should interact to make the Job done.
We are using collection of root object for performance purpose; our application is managing big sets of data. Using EditableRootListBase<T> allow us to build changeset easyly, this way we avoid passing big collection of data to the second tier.
So is there a way to avoid root object being saved by the apply edit ?
One way could be to override SaveItem but I’m realy not sure it is the best choice.
Thanks
albator:
Nothing says that good object design must use only one object for a use case. Multiple objects should interact to make the Job done.
We are using collection of root object for performance purpose; our application is managing big sets of data. Using EditableRootListBase<T> allow us to build changeset easyly, this way we avoid passing big collection of data to the second tier.
You should be designed objects to fulfill use cases. Only after you have done so should you look at performance, and you should strive not to sacrafice design for performance.
So is there a way to avoid root object being saved by the apply edit ?
The behavior ERLB doesn't seem to fit your requirements, so I wouldn't suggest using it for this use case. That class was added recently specifically to allow editing of root objects in a collection, whose changes should be saved after the grid commits the row.
What you probably want is a BusinessListBase root object, but then all the items contained in the list would have to become children. Since the objects should now be children, they should probably be different objects in their own right. You might be able to create a switchable object (one that can be a child or root), but this usually indicates a design problem, and you should proceed with caution.
Thanks for helping ajj3085,
I was trying to be succinct and bypass lots of business and design issues and used the performance aspect as a shortcut to explain the design which is of course wrong. Those root objects must indeed be root objects but while there is a performance benefit this is not the main reason. Those objects are used/refered by other objects but they do not "belong". They can be on their own or, if you prefer, "switch parent". And we are not reusing objects at all.
I think there are legitimate reasons to save multiple root objects in the same transaction although I admit it is the first time we have to deal with an ERLB. We are doing it with a command object that wraps the entire transaction from Rocky's recommendation (we met him before the ERLB issue and ERLB was not discussed at the time).
We may have goofed, but those objects are root objects because of their designed behaviors and we need a collection (in fact collections) of them and we must save them (the roots, not the collections) in a common batch transaction. This is working fine (we may not see the train ahead and this is also why we are posting) and the only issue is with the grid that is calling apply edit and bypassing transaction logic.
It seems to me that ERLB is assuming too much in this case by allowing the UI to take too much control.
I think that a switch for disabling save on apply edit could be a good solution.
Thanks
I think there are legitimate reasons to save multiple root objects in the same transaction although I admit it is the first time we have to deal with an ERLB.
You are trying to do something outside the design parameters for ERLB.
It seems that you have at least two options.
One is to override SaveItem(). I made this method virtual/Overridable primarily with the idea that you could add validation logic, but there's no reason you couldn't entirely override it to do some other type of update operation.
Another is to copy ERLB and use it as a base to make your own, where the save operation isn't handled by the collection itself, but perhaps the collection raises an event so the UI can initiate the save as it sees fit.
Of the two, I think I'd do the first option. Just make sure you handle the edit level properly - which probably means copying the existing SaveItem() code from ERLB and replacing the call to the Save() method with your alternate code.
Copyright (c) Marimer LLC