Need help using custom Serializer for CSLA object.

Apr 12, 2011 at 11:12 PM

I am trying to get Sterling to handle CSLA objects.  There is a CSLA serializer, the MobileFormatter, that handles everything.  In order for an object to be serializable with the Mobile Formatter it must implement the IMobileObject interface.  I've setup my custom serializer and it is checking correctly for the IMobileInterface and things are almost working however I'm getting stuck deserializing.  I'm not sure if my problems are just how I'm trying to call the deserialize or if it has to do with the Lazy Loading or something along those lines.

The object I'm trying to Save is a 'complex' type with multiple ReadOnly lists (CSLA objects). 

I can do the following no problem to serialize to IsoStorage:

settings[myAppSettingsKey] = MobileFormatter.Serialize(myCslaObject);

To retrieve it,

myCslaObject = MobileFormatter.Deserialize( (byte[]) settings[myAppSettingsKey]) as MyBusinessObjectType;

I can''t seem to be able to get the syntax correct in the overriden Deserialize(Type, type, BinaryReader reader) method though.  I don't know if I should be using the whole stream or if just a portion of the stream is my object.  Depending on what I try I'm getting errors that indicate I have bad syntax in the stream or just basic failures.  I noticed from the examples that one should do a Readxxx() as if reading each piece of the object.

Deserialize(Type, type, BinaryReader reader)()


            var buffer = new byte[reader.BaseStream.Length];
            reader.Read(buffer, 0, (int)reader.BaseStream.Length);
            var obj = MobileFormatter.Deserialize(buffer) ;


Now part of the problem may be that the MobileFormatter only works on the object as a whole, not on the children as chunks?  I notice when it serializes it passes in all the children first as individual objects.

Any thoughts?



Apr 15, 2011 at 2:56 AM

One problem may be the read-only. Sterling only supports properties with public getters and setters. It will completely ignore ones that don't have setters because it would not be able to deserialize them (it needs a setter to set it up for the deserialization). You could set the serializer to the "parent" type and then new up the list. I don't know enough about CSLA to understand what the specific problems are. Basically the concept of the serializer is that you are somewhere inside a stream, and you have x, y, and z. So you write out x, y, z and then on the deserialization, you are responsible for creating the type, reading x, y, z out and setting it up and then passing the type back.

Apr 15, 2011 at 3:16 AM

The ReadOnly would be a problem if I didn't have the CSLA mobile formatter but it knows how to serialize/de-serialize it.

I think the issue though may be related to the idea of being 'inside a stream'.  The CSLA MobileFormatter expects the whole stream but I think Sterling is passing me it back in pieces as I have a parent object with numerous child lists.

1) Is there anyway for Sterling to not try to pull the object apart and just have a 'Serialize as single chunk' and deserialize as single chunk?

2) When I get passed the reader it has a base stream ... does that stream include anything else?

My object is basically like this:

class ParentCacheObject


public List<SomeObject> LookupCodeList1{get;set;}

public List<SomeObject2> LookupCodeList2{get;set;}


The CSLA serializer will serialize ParentCacheObject to a single stream, that is what I return in my Serialize() method and I need the exact same string back in the DeSerialize() method to return the object.  I can't do:

var List1 = Reader.ReadSizeOfList1

var List2 = Reader.ReadSizeOfList2

var newParent = new ParentCacheOBject {LookupCodeList1= List1, LookupCodeList2=List2}

return newParent;

I need to do like above => var newParent = MobileFormatter.Deserialize(Buffer) as ParentCacheObject;


Does that make sense?  Would it be hard to come up with a way to put a [SerializeAsSingleEntity] attribute so the serializer is almost dumb and doesn't try any of the childParent stuff?  That is even assuming I'm correct on that standpoint.




Apr 15, 2011 at 3:56 AM

The whole point of Sterling is to provide a rich serialization experience with the added benefits of keys and indexes. I don't understand why you are trying to use it when you have an existing serialization strategy. To me it makes sense to either go with the strategy that CSLA has, or use the Sterling strategy and focus on serializing the objects rather than depending on their serializer. There is no such thing as "serialize as a single entity" because the object graph is recursed, so the operation must begin and end with an existing stream. You can suppress items from being serialized by using the ignore attribute but that problem is that the serializer you are using is expecting it's own stream to read through to the end so it just doesn't make sense to plug into Sterling, unless I am missing something.

Apr 15, 2011 at 2:08 PM


Thanks for the reply and your time– you are correct in that the choice of trying to push this particular object into Sterling is foolish. I don’t gain from any of the indexing or keys as it is a single object with a bunch of lists to cache. It is just the first big object I wanted to persist so I may be guilty of trying to push a square peg in a round hole.

I do however want to be able to cache CSLA objects but I shouldn’t be caching the lists, I should be pushing the individual objects in. I will revisit that and see how it goes.

What I meant by ‘entire entity’ was to allow the CSLA serializer to handle the entire object graph (which it does fine) in one pass as opposed to Sterling. If Sterling handles it then doesn’t the de-serialization gets broken up into chunks as it puts the object back together?

I was hoping it worked like the below regardless of the objectGraph in MyCslaObject which contains both primitive and Csla types:

Database.Save(MyCslaObject) -> CustomSerializer(MyCslaObject) -> MobileFormatter.Serialize(MyCslaObject) -> Bytes[] -> IsoStorage[MyCslaObjectType, Key) ->

Database.Load(MyCslaObject.LazyValue.Value) -> CustomDeSerializer(MyCslaObjectType, 100% Bytes[]) -> MobileFormatter.Deserialize(bytes[]) -> MyCslaObject

I’ve obviously left off all the useful Sterling stuff with keys/indexes etc.

Am I totally out to lunch?


Apr 15, 2011 at 2:32 PM

So Sterling MUST do it as "chunks" in the same stream to handle complex, recursive object graphs. It must stream out the parent, then the child class, it's child, and so on. It must also do this in a continuous stream or else the performance cost would be prohibitive. I believe the issue is with the design of the mobile formatter ... instead of serializing into a stream, it expects to take charge of the entire stream and write or read to end, which isn't supported by Sterling because that would defeat the recursive/complex object graph functionality that it provides.

Apr 15, 2011 at 2:53 PM

Which makes sense and jives with what I was seeing. Thanks for the clarification.

Too bad I took a bad use case as my first attempt; although I did learn lots about the Sterling Code which always helps in the end. I think I read the example with a single item using a Key of True almost right off the bat .

I will have another go with some more simple types. When it boils down to it my caching / persistence needs are either a few large complex objects (no benefit for indexing etc.) where Sterling is a bad fit or lists of simple types. Once I can adjust my server DAL layer to return simple nonCSLA objects I believe I can basically make a local DAL that reads/writes to Sterling. Then I’ll be able to take full advantage.

I do have some more complicated types with larger object graphs but I think I can actually decouple them which would give me some huge benefits either way or I have to add a custom serializer that works at the exact object type level vs. a generic interface.

Thanks a lot for helping me work through this. I know I have a number of other open questions so hopefully you can help me out with those as well.