Best way to handle IList<T> properties

Nov 30, 2010 at 8:25 AM

What's the best way to handle a sub collection of entities? I have an object model like the following

class EntityA
  public string Id { get; set; }
  public string Title { get; set; }
  public IList<EntityB> Children { get; set; } 

class EntityB
  public int Foo { get; set; }

I'd like sterling to handle this for me (like does), but I just get null collections on deserialize.  I think I have 3 options:

  • The documents seem to suggest that Sterling will recognize IList<EntityB> if I create a table for EntityB (but I haven't been able to get that to work).  
  • I could write a serializer for IList<EntityB>, but that seems like the wrong way.
  • I could remove the IList property and just store the children in their own table directly.  I could then query/join when I needed parent and child based on an id.
Nov 30, 2010 at 10:50 AM

Currently, Sterling handles List<EntityB> just fine. The problem with IList<EntityB> is the propery is declared as an interface, and Sterling uses the property definitions to re-serialize objects. On the de-serialization phase, because the type is an interface, Sterling doesn't know the correct implementation and can't new an IList.

There is a feature request already in place for Sterling to serialization the type of the implementation so it can be properly de-serialized on load. That will go into the next release. For now, if you can live with an implementation type for the property (List<EntityB>) instead of an interface (IList<EntityB>) it will work.

Nov 30, 2010 at 5:29 PM

Thanks, List works better. You might want to update the documentation


"Otherwise, it will serialize based on any of the existing BinaryWriter overloads. These include: bool, byte, byte[], char, double, float, int, long, sbyte, short, string, uint, ulong, and ushort. Sterling automatically handles IList of any of the previous types, and has a special serializer for DateTime, Guid, and Uri (Guid support is not present for the Windows Phone 7 due to the lack of the Parse method). "


One other issue I'm getting with serialization is that Sterling gives an exception when properties are null. In the example above, if EntityB had a string property called Name, which was null.  The serializer blows up.  It works fine if I make the value an empty string.  Is this expected behavior? Are you planning on supporting null values?