Gary's Blog

Problem

You want to serialise an object as quickly as possible and you have no preference as to which RDBMS is used.

Solution

using System;
using DevExpress.Xpo;

class Program {
    static void Main(string[] args) {
        //GS - Create a unit of work to work within
        using (UnitOfWork uow = new UnitOfWork())
        {
            //GS - Create and serialize a person
            Person person = new Person(uow) { 
                FistName = "Gary", 
                LastName = "Short", 
                DateOfBirth = DateTime.Parse("24/01/1970") 
            };

            uow.CommitChanges();
        }
    }
}

//GS - Define a Person Class
public class Person : XPObject {
    public Person(Session session)
        : base(session) { }

    private string _FistName;
    public string FistName {
        get {
            return _FistName;
        }
        set {
            SetPropertyValue("FistName", ref _FistName, value);
        }
    }
    private string _LastName;
    public string LastName {
        get {
            return _LastName;
        }
        set {
            SetPropertyValue("LastName", ref _LastName, value);
        }
    }
    private DateTime _DateOfBirth;
    public DateTime DateOfBirth {
        get {
            return _DateOfBirth;
        }
        set {
            SetPropertyValue("DateOfBirth", ref _DateOfBirth, value);
        }
    }
}

Discussion

The first thing to notice is that I have more than one class defined in my source file. Such things are normally frowned upon in favour of a “one class, one file” mantra, and rightly so. However, I am not writing an application for production here, I’m writing code for a blog post and it makes it easier to discuss if all the code is displayed; it also makes it easier for you to cut, paste and run the example if you so wish. I will be defining all my classes in the one source file for all of the recipes in this cookbook, but I will only be explaining the rationale once. If you wish, you may take bets on how far into the cookbook I get before someone comments along the lines of “shouldn’t you have one file per class?”. When they do, the reader who guessed closest to the recipe number wins; when it happens you can also point the commenter here for an explanation. :-)

Anyway, on to the explanation of the recipe. Firstly let’s chat about the business object we have created for serialisation. The first thing to notice is that our class inherits from XPObject, one of three classes that your business objects can inherit from when using XPO, more on the other two in future recipes. XPObject gives us support for unique keys and optimistic locking out of the box and is the class inherited from if you use the CodeRush template to create your business object. The CodeRush template is the recommended way to create such business classes and is the route I always take. The mnemonic for this template is “xc”.

The next thing to notice about our business object is the setter for the properties uses the SetPropertyValue method, this allows XPO to handle change management for you and is one less thing for you to worry about. The CodeRush templates for adding these properites (“xps” for string properties and “xpd8” for the DateTime property) adds the call to SetPropertyValue for you and is, again, the recommended route.

To make use of our business object we create a UnitOfWork. The UnitOfWork inherits from Session and the benefit it gives us developers is that we no longer have to keep track of all the changes to our persistent classes ourselves. When we used the Session object each instance of our business objects had to be sent the Save() message in order to be persisted. When using UnitOfWork this is no longer the case, the UnitOfWork tracks all the changes for you and they are persisted by making one call to CommitChanges() once you have made all the required changes to all of your objects and you are ready to serialise your object graph.

The last thing to mention is that the default persistence mechanism is to serialise the object graph to an Access database. We shall examine how to change this default behaviour in a future recipe.