I have a project that is a pretty standard CSLA + Silverlight implementation using WCF and Compression and it works very well.
I discovered that one of my BO's (and related object graph) serialises to a very large payload.
Take scenario 1
The BO is structured as follows:
RootList (AL)
|
|---> Child (A)
|
|------>ChildList (BL)
|
|--------->Child (B)
All of the objects are editable and have the simplest properties on them:
A
B
So at runtime I have AL containing about 150 intances of A, and each A has about 150 instances of B in BL. When that is serialised from ASP.NET by the MobileFormatter it comes to a whopping 110Mb!!!
This seems excessively bloated because if I change the object graph to NOT have BL and B and store the 150 RefIdA and RefIdB in a different structure, it reduced by a dramatic margin. Below is more information on the new object graph.
Take scenario 2
RootList (AL)
|
|---> Child (A)
Instead of BL+B, I define on A a List/Collection property to represent the integer values that would otherwise have been stored in BL+B (for example a MobileList<int,int>). To my surprise the serialization size drops a massive 90% to only 9Mb.
To point I'm making is that with scenario 2, the object graph I'm essentially still has150 instances of A and each A still has a collection with 150 instances of two integers. I do understand that with scenario 2 I'm no longer serialising a BusinessListBase containing BusinessBase objects and that the BLB and BB objects are a great deal larger than just a collection structure of 2 integers.
My question is whether it is whether the larger more complicated BusinessListBase+BusinessBase objects is really that much larger to justify the inflated size when serialized such that is almost ten times larger? Or could there be a bug or performance improvement be made?
Unfortunately my understanding of the MobileFormatter and related bits is lacking to know what it should and shoudn't be doing.
Apologies if this is tad verbose and tricky to follow. Please let me know if anything is unclear and I will try to explain more clearly.
Thanks for reading,
Jaans
Copyright (c) Marimer LLC