Using XmlSerializer to Persist Application Data and Settings for my Code Generator and Database Explorer

My code generator and database explorer is getting useful enough that I need to start persisting application data and settings.

When I create a new project, the code generator reads the database schema from the database.  This information is stored in an object hierarchy.  Once I have the database schema information, I can add and modify metadata to the existing schema to customize the generation of classes, stored procedures, and user interface controls.

It is this custom metadata and database schema that I need to persist so that one doesn't have to re-create this information each time.  An added benefit of storing this information offline is that I don't have to be connected or re-connect to the database to do code generation.  Once I have the schema, I can be on a plane, at the beach, or anywhere else and still do code generation without needing a connection to the database.

Pesky Code Generator File Menu

So now my pesky file menu which only had a working “New Project...” option now has to start saving and opening project data and settings.  Shown is a very slim File menu that will probably need to be beefed up in the future.

 

 

New Project with Support for SQL Server Express

The “New Project...” menu is your basic connect to a server and log on to a database sort of dialog, which I closely modeled to the dialog that exists in Visual Studio 2005.  One of the recent changes I made was support for SQL Server Express database files.  Now I can either connect to a server or attach to a database file.

 

 

XmlSerializer to Persist Application Data and Settings

There are so many quirky nuances about the XmlSerializer that make it problematic or useless for complex data and settings.  However, for simple data types it works just fine as long as you make sure your classes have default constructors, read/write properties or public fields of the data you want to persist, etc.  XmlSerializer stores data as XML, which makes it easy to read, easy to debug, and easy to change manually in your favorite text editor.

All my project data and settings sit within a class called MyProject.  The MyProject Class holds the database schema and all metadata and settings for the project.

Persisting an instance of this MyProject Class using XmlSerializer is as simple as follows:

 

public void Save(string filename)
{
    XmlSerializer serializer =
        new XmlSerializer(typeof(MyProject));

    using (Stream writer =
        new FileStream(filename, FileMode.Create))
    {
        serializer.Serialize(writer, this);
        writer.Close();
    }
}

 

Loading an instance of the MyProject Class is just as easy:

 

public static MyProject Load(string filename)
{
    XmlSerializer serializer =
        new XmlSerializer(typeof(MyProject));

    MyProject project;

    using (Stream writer =
        new FileStream(filename, FileMode.Open))
    {
        project = (MyProject)serializer.Deserialize(writer);
        writer.Close();
    }

    return project;
}

 

XmlSerializer takes the class type in its constructor and can serialize and deserialize to a FileStream that holds the class data.  Sure beats writing my own persistence solution.

 

Conclusion

XmlSerializer is a decent, but far from perfect method of persisting application data and settings.  If your needs are simple as they are in the case of my code generator and database explorer, avoid the hassle of writing your own persistence methods and take advantage of classes, like XmlSerializer, that are built into the .NET Framework.

 

Recent .NET Development Tutorials

 

Posted by David Hayden ( Florida .NET Developer )

posted on Saturday, December 17, 2005 2:11 PM

Main

News

Green Tea

.NET Development

Enterprise Library

Patterns & Practices