Hi
I have a screen in Silverlight which is comprised of a header record, and then a datagrid which might contain up to 1000 records.
The user doesn't want to use paging and would prefer to just scroll down the list of records in the datagrid and enter a value in one of the cells for what could be just a handful of records.
When the user clicks Save the entire object is transported back to the server, including the 1000 odd records. This is resulting in some poor performance (even with compression).
Is there any technique you might suggest to handle this kind of suggestion?
The question is being asked..."why are we transporting back every record if we're only editing three?".
Thanks
Damien
Hi,
Look at the DiifGram sample in the samples folder (or fork the entire repository on GitHub).
This samples is showing a technique for just what you want - only sending back a few records from a large list.
I think this will help. Thanks for that.
Just out of curiosity, has there ever been any thought put into the option of 'flagging' your objects to only transfer if changed?
I understand there are many occasions where we want the entire graph transferred to the server, but in our application there's plenty of times we don't really need to.
No,
it has been suggested previously but is not planned.
You must also remember that CSLA requires a "binary formatter" and supports both .NET builtin formatters (BinaryFormatter and NetDataContractSerializer) plus the CSLA specific formatters. If CSLA was to only send "flagged" objects it would require that CSLA created a new object structure with only the objects to send and then serialize that structure and then when the result came back (deserialized) to update the original object structure.
Remember also that
var newInstanceOfStructure = OldInstance.Save()
IE: Save should return a new instance of the complete structure.
Hi,
Are you sure poor performance is caused by serialization and communication?
Using WPF we found that 70% performance is WPF (mainly layouting) and "only" 30% the DataPortal calls. We would have expected the other way round...
The idea of DiffGram is certainly a good one.
We're caching static data (lookup data) but don't include them (using a non-serialized backing field).
Stefan
One more thing to consider; right now you have 1000 or more child items in a root object but the user only edits a few at a time. Are you sure its really necessary to have this design? That is to say, does each child really need to be saved in the context of its parent, or can the child be saved independently? That was something I struggled with at first with Csla. While line items on an order probably can't be saved outside the context of a containing order, a list of notes associated with a contact can probably allow each note to be saved independently; the fact that a note must be tied to a contact does not mean that a Contact class must contain a child list of ContactNotes.
Whenever you have thousands of rows on the screen it raises a flag to me that they probably aren't going to be children. Thinking about the order, is it likely for an order to ever have thousands of line items? Probably not.
One more thing to consider; right now you have 1000 or more child items in a root object but the user only edits a few at a time. Are you sure its really necessary to have this design? That is to say, does each child really need to be saved in the context of its parent, or can the child be saved independently? That was something I struggled with at first with Csla. While line items on an order probably can't be saved outside the context of a containing order, a list of notes associated with a contact can probably allow each note to be saved independently; the fact that a note must be tied to a contact does not mean that a Contact class must contain a child list of ContactNotes.
Whenever you have thousands of rows on the screen it raises a flag to me that they probably aren't going to be children. Thinking about the order, is it likely for an order to ever have thousands of line items? Probably not.
If the child can be saved independently of the parent, the design can use DynamicRootList / DynamicRoot stereotypes.
DynamicRootList loads its children as any parent object would do, but doesn't save them, The save part is handled by DynamicRoot objecs themselves. This binds beautifully to datagrids.
All good suggestions. Thanks gents.
You could argue that it's poor UI design, but for a program like a Stocktake or Purchase Order, this is how they prefer to work with their data ie bulk select records and update only those they're interested in.
Users don't want to individually select records in these kinds of screens. They want to bulk select ie by a category, instead. This saves then a great deal of time when entering data.
All good suggestions. Thanks gents.
You could argue that it's poor UI design, but for a program like a Stocktake or Purchase Order, this is how they prefer to work with their data ie bulk select records and update only those they're interested in.
Users don't want to individually select records in these kinds of screens. They want to bulk select ie by a category, instead. This saves then a great deal of time when entering data.
My suggestion isn't so much that you abandon the current UI, just re-evaluate if the object which represents a row should be a Csla child object instead of a root; as suggested above and DynamicListBase allows you to do this which will save each row as the user leaves it.
If we went with a DynamicListBase, I'm assuming it would mean we'd lose the ability for the user to undo their changes?
Our UI has a cancel button which we then use to tap into CSLA's n-level undo functionality.
Hi Damien,
You are right. Binding DynamicListBase to a DataGrid each row is saved as soon as you leave the row. So no undo is available for that row, after it's saved.
Copyright (c) Marimer LLC