I'm looking at improving my local caching and maybe implementing one of the opensource client side databases / caches. All the solutions involve serializing and compression/encypting the data.
If I have the option should I copy CSLA and let the Mobile Formatter to do it or just let the standard serialization process do it? Would I see any performance gains?
Thanks
jack
You don't say what exactly you're saving the data for, but in general it's not recommended you serialize CSLA objects directly to persistent storage (e.g. isolated storage, local database, etc.) That's actually not just a CSLA recommendation; directly serializing any object for some length of time beyond a user's session potentially introduces some versioning issues. Plus, I'm not sure you could serialize all the metadata that you'd need to completely dehydrate/rehydrate objects in Silverlight, even with the MobileFormatter. I'm certain the serialization processes available within SL won't cut it - otherwise the MobileFormatter wouldn't be necessary.
In general, if you need to do something like this, it's better to develop a separate serialization format that captures the data you need. The trick is developing a format that's forgiving to change, since you still have the versioning issue to contend with. But it's easier to contend with than trying to write out your CSLA object graph as-is.
If your caching needs are just a per-session kind of thing, is there a reason static variables don't do the trick?
HTH
- Scott
Scott,
I'm looking at caching data that really won't change very often, is really simple, and in the event of an application re-build can be simply blown away. It is all read-only application data and lookup codes etc. I have some clients with horrendous internet connections so I'm trying to alleviate as much over the wire as possible.
I've been playing with the Sterling DB which works great for non-CSLA objects but I'm having issues plugging in the mobileFormatter as a custom serializer.
I may take you advice and ditch CSLA objects for a lot of this data and make it simpler.
Jack
Copyright (c) Marimer LLC