locked
Best way to persist desktop application data RRS feed

  • Question

  • I author a desktop app which needs to persist its data to disk. The data is an object graph. Which way would you recommend to do it?


    1. Use .Net data contract serialization to serialize the whole graph. However the resulting xml seems daunting and when the object model will change in the next version data migration seems hard.

    2. Build a flat DTO for the model (no recursive references, no inheritance) and serialize it to SQLite (or xml). Migration here seems easy but it requires another layer to translate the BL objects to DTO.

    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Tuesday, August 31, 2010 7:58 PM

Answers

  • I would serialize using option1. When you upgrade, make an object upgrader. Just version the class output when you write to disk, so you can tell if the object serialized is 'old' or 'new'.
    • Marked as answer by Yaron Naveh Thursday, September 2, 2010 8:35 PM
    Tuesday, August 31, 2010 8:55 PM
  • I would also go for option one, I would make the object upgrader a seperate component in your applications setup. With would only run ones during install/upgrading. Don't make it part of you codebase put it in a separate dll.

     

    HtH

     

    Hans

    • Marked as answer by Yaron Naveh Thursday, September 2, 2010 8:35 PM
    Wednesday, September 1, 2010 1:50 PM

All replies

  • I would serialize using option1. When you upgrade, make an object upgrader. Just version the class output when you write to disk, so you can tell if the object serialized is 'old' or 'new'.
    • Marked as answer by Yaron Naveh Thursday, September 2, 2010 8:35 PM
    Tuesday, August 31, 2010 8:55 PM
  • This would require me to ship with all my old models each time. This complicates deployment. Also I cannot load to memory two classes from the same dll (in different version) at the same time. so I would need to increase a sequential number in the class in the end of each iteration to qa...
    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Tuesday, August 31, 2010 9:10 PM
  • Maybe I am not understanding all the details then.
    Wednesday, September 1, 2010 1:01 PM
  • I would also go for option one, I would make the object upgrader a seperate component in your applications setup. With would only run ones during install/upgrading. Don't make it part of you codebase put it in a separate dll.

     

    HtH

     

    Hans

    • Marked as answer by Yaron Naveh Thursday, September 2, 2010 8:35 PM
    Wednesday, September 1, 2010 1:50 PM
  • Hans

    So you mean I will not do migrations on the xml itself, but do a object-2-object mapping from old model to new model. The upgrader will contain both models, so I should not throw a way the code after each version but ship with it in all following upgraders. Is that what you mean?


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Wednesday, September 1, 2010 5:41 PM
  • I meant this as well. Sorry it wasn't clear. Good luck.
    Thursday, September 2, 2010 1:33 PM
  • Why would you put your data in xml if you could put it in a database?

    OK, sometimes you can't use a database because the data is weird. 

    If your data can fit in a database then I'd just go with a database.  Ship a new one, load all the data across.  Check it.  Drop the old database, or mark it for deletion a week later or something.

    There's a good reason people invented databases.

    I also took it as a given that a custom upgrade script goes in an upgrader that the user runs once.

    You don't run setup every time you run Word.

    Thursday, September 2, 2010 8:37 PM
  • Hi Yaron,

     

    You will migrate the xml by loading in your data via the old datamodel transform it to the new object model via object 2 object mapping. And save it to xml again. This logic is only contained within your upgrader, not in your application code.

    Make your application work only with a certain version of the xml, and supply a upgrader per version upgrade

     

    1.0 to 1.5 upgrader

    1.5 to 2.0 upgrader

    2.0 to 2.5 upgrader

     

    It's up to you if you want to supply all upgraders with every version you release or just with the last one.

     

    Cheers,

     

    Hans

    Tuesday, September 7, 2010 8:22 AM
  • Hi Hans

    This did seem the right solution at some point. However the product is being developed by a large group of developers. I would need to supply such an "upgrade" after every change one developer makes and propagate it to other developers (in order to upgrade their local assets). Having a model for each such change is not scalable.


    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog
    Tuesday, September 7, 2010 12:23 PM