views:

218

answers:

1

I'm looking for a way to persist Silverlight objects to a user's PC, then re-hydrate them so the user can finish editing them.

Serialising with DataContractSerializer and persisting to IsolatedStorageFile works fine. However, deserialising causes a problem. Here's the code that causes the failure:

private string _FirstNames = string.Empty;
public string FirstNames
{
    get { return _FirstNames; }
    set
    {
        new PersonNameValidator().Validate(value);  //<-- BOOM 8(
        Set(ref _FirstNames, value, () => this.FirstNames);
    }
}

The deserialiser calls the property setter, which in turn throws an exception and aborts the deserialisation.

I've tried explicitly applying DataContract/DataMember/IgnoreDataMember attributes, but then it doesn't play nicely with private fields:

System.Security.SecurityException occurred Message="The data contract type 'Trident.Model.Journey.JourneyApplication' cannot be serialized because the member '_TravellerSavingsAmount' is not public. Making the member public will fix this error. Alternatively, you can make it internal, and use the InternalsVisibleToAttribute attribute on your assembly in order to enable serialization of internal members - see documentation for more details. Be aware that doing so has certain security implications."

How can I bypass the property setters during deserialisation?

I'd like to keep my classes focused on the domain, and not too polluted with infrastructure concerns.

A: 

A couple of ideas:

  • serialize a property that is used only for serialization thereby bypassing any validation
  • serialize a parent class and use a derived class for validation
Joel Lucsy
Thanks Joel. I considered the first point, but dislike the idea of adding extra public properties/fields just to support serialisation.As for using derived classes: this could get cumbersome as my object graphs increase in complexity. I don't want to write a custom routine to handle every object graph I create.
Vijay Patel