19 Jul 2015 @ 5:54 PM 

For some time I have been working on and off on an attempt to create a useful, powerful, and easy to use library to help with serializing and deserializing data instances to and from XML. Without repeating too much, the core concept is to have an IXmlPersistable interface implemented by classes, or to have an IXmlPersistableProvider implementation made available that the library can associate with that type to save/load instances to and from an XElement node.

For the most part, it has gone quite well. However I hit some interesting snags with regards to Generic types, particularly, Generic types that I want to write IXmlProvider implementations for. For example, let’s say we want to support serializing and deserializing a List<T>. We obviously cannot implement every single permutation of IXmlProvider<List<T>>, since implementing an interface requires a concrete class definition. What this means is that if I wanted to support saving/reading a List via a PersistableProvider, I would need an implementation that implements IXmlPersistableProvider<List<String>> and so on for each possible type- which means of course that types that I don’t know about at compile time could never be included. Unfortunately the logic is too complex to embody via generics- really, I’d want an implementation of IXmlPersistableProvider<List<T>> where T was any type that itself either implemented IXmlPersistable or for which there was an available IXmlPersistableProvider<T>. So clearly I needed to find an alternative approach.

My first consideration/implementation was to not have any sort of Provider at all; instead, I created a SaveList<T> method and a corresponding ReadList<T> method, which would attempt to save each element T of the List by using the generic SaveElement<T> method I created:

However I soon discovered that there was a bit of a caveat to that approach. In my case I discovered it after expanding to create a similar construct for Dictionaries. If there was Dictionary where either the key or the value type was a List, than it wouldn’t work properly- as there is no implementation of the Providers or interface to save/read a List! So it was back to the drawing board. it was then that I decided that while I couldn’t implement a all-emcompassing IXmlPersistableProvider for the List<T> type, I could have an implementation that covered IList and IDictionary, which are interfaces implemented by the List and Dictionary generic types respectively. There is still a caveat in that saving a Dictionary<String,List<String>> will save properly, but calling ReadElement will instead return a Dictionary<String,IList>, but for the moment I cannot determine a reasonable method to do otherwise within the framework I have created. For now I’m thinking that can be a sort of advisory for the actual Persisting code to keep in mind if it ever needs to save/load nested Generic types.

Have something to say about this post? Comment!

Posted By: BC_Programming
Last Edit: 19 Jul 2015 @ 05:54 PM

EmailPermalink
Tags
Tags: , ,
Categories: .NET, API, C#, Windows


 

Responses to this post » (None)

 

Sorry, but comments are closed. Check out another post and speak up!

Tags
Comment Meta:
RSS Feed for comments

 Last 50 Posts
 Back
Change Theme...
  • Users » 47469
  • Posts/Pages » 384
  • Comments » 105

PP



    No Child Pages.

Windows optimization tips



    No Child Pages.

Soft. Picks



    No Child Pages.

VS Fixes



    No Child Pages.