serializing type definitions?

Question

I'm not positive I'm going about this the right way. I've got a suite of applications that have varying types of output (custom defined types).

For example, I might have a type called Widget:

Class Widget
      Public name as String
End Class

Throughout the course of operation, when a user experiences a certain condition, the application will take that output instance of widget that user received, serialize it, and log it to the database noting the name of the type.

Now, I have other applications that do something similar, but instead of dealing with Widget, it could be some totally random other type with different attributes, but again I serialize the instance, log it to the db, and note the name of the type. I have maybe a half dozen different types and don't anticipate too many additional ones in the future.

After all this is said and done, I have an admin interface that looks through these logs, and has the ability for the user to view the contents of this data thats been logged. The Admin app has a reference to all the types involved, and with some basic switch case logic hinged upon the name of the type, will cast it into their original types, and pass it on to some handlers that have basic display logic to spit the data back out in a readable format (one display handler for each type)

NOW... all this is well and good...

Until one day, my model changed. The Widget class now has deprecated the name attribute and added on a bunch of other attributes. I will of course get type mismatches in the admin side when I try to reconstitute this data.

I was wondering if there was some way, at runtime, i could perhaps reflect through my code and get a snapshot of the type definition at that precise moment, serialize it, and store it along with the data so that I could somehow use this to reconstitute it in the future?

Answer 1

I haven't needed to do this since back in the MFC days were it was quite a manual process, so will work differently in .Net, but maybe this can be useful anyway. The way we solved it then was that when we serialized anything we also wrote a version number and we only added new bits of data to write, we never removed or amended anything (though we'd output empty data, so if for example the name was removed, we'd write it as an empty string).

Then the deserializer would use a lot of if statements where it would only read certain parts of data if it was over version X, and when it had read in everything mentioned in the deserializer, it ignored anything after that.

The big advantage with doing it this way was that the data could be read by both older and newer versions of the app, though obviously it would only work if the app could use some suitable defaults for any missing data, but that shouldn't really be a problem if all you want to do is look at the data in the admin tool, and would give you the advantage that it's less urgent to update the admin tool every time you make a change to your models.