capture changes to properties of an object

Question

I have multiple business objects in my application (C#, Winforms, WinXP). When the user executes some action on the UI, each of these objects are modified and updated by different parts of the application. After each modification, I need to first check what has changed and then log these changes made to the object. The purpose of logging this is to create a comprehensive tracking of activity going on in the application.

Many among these objects contain contain lists of other objects and this nesting can be several levels deep. The 2 main requirements for any solution would be

1. capture changes as accurately as possible
2. keep performance cost to minimum.

eg of a business object:

public class MainClass1
{
    public MainClass1()
    {
        detailCollection1 = new ClassDetailCollection1();
        detailCollection2 = new ClassDetailCollection2();
    }

    private Int64 id;
    public Int64 ID
    {
        get { return id; }
        set { id = value; }
    }

    private DateTime timeStamp;
    public DateTime TimeStamp
    {
        get { return timeStamp; }
        set { timeStamp = value; }
    }

    private string category = string.Empty;
    public string Category
    {
        get { return category; }
        set { category = value; }
    }

    private string action = string.Empty;
    public string Action
    {
        get { return action; }
        set { action = value; }
    }

    private ClassDetailCollection1 detailCollection1;
    public ClassDetailCollection1 DetailCollection1
    {
        get { return detailCollection1; }
    }

    private ClassDetailCollection2 detailCollection2;
    public ClassDetailCollection2 DetailCollection2
    {
        get { return detailCollection2; }
    }

    //more collections here
}

public class ClassDetailCollection1
{
    private List<DetailType1> detailType1Collection;
    public List<DetailType1> DetailType1Collection
    {
        get { return detailType1Collection; }
    }

    private List<DetailType2> detailType2Collection;
    public List<DetailType2> DetailType2Collection
    {
        get { return detailType2Collection; }
    }
}

public class ClassDetailCollection2
{
    private List<DetailType3> detailType3Collection;
    public List<DetailType3> DetailType3Collection
    {
        get { return detailType3Collection; }
    }

    private List<DetailType4> detailType4Collection;
    public List<DetailType4> DetailType4Collection
    {
        get { return detailType4Collection; }
    }
}

//more other Types like MainClass1 above...

I can assume that I will have access to the old values and new values of the object.

In that case I can think of 2 ways to try to do this without being told what has explicitly changed.

1. use reflection and iterate thru all properties of the object and compare those with the corresponding properties of the older object. Log any properties that have changed. This approach seems to be more flexible, in that I would not have to worry if any new properties are added to any of the objects. But it also seems performance heavy.
2. Log changes in the setter of all the properties for all the objects. Other than the fact that this will need me to change a lot of code, it seems more brute force. This will be maintenance heavy and inflexible if some one updates any of the Object Types. But this way it may also be preformance light since I will not need to check what changed and log exactly what properties are changed.

Suggestions for any better approaches and/or improvements to above approaches are welcome

Answer 1

I developed a system like this a few years ago. The idea was to track changes to an object and store those changes in a database, like version control for objects.

The best approach is called Aspect-Oriented Programming, or AOP. You inject "advice" into the setters and getters (actually all method execution, getters and setters are just special methods) allowing you to "intercept" actions taken on the objects. Look into Spring.NET or PostSharp for .NET AOP solutions.

Answer 2

I may not be able to give you a good answer, but I will tell you that in the overwhelming majority of cases, option 1 is NOT a good answer. We're dealing with a very similar reflective "graph-walker" in our project; seemed like a good idea at the time, but it is a nightmare, for the following reasons:

• You know the object changed, but without a high level of knowledge in the reflective "change handling" class about the workings of objects above it, you may not know why. If that information is important to you, you have to give it to the change handler, most l;ikely through a field or property on the domain object, requiring changes to your domain and imparting knowledge to the domain about the business logic.
• Changes can affect multiple objects, but logs for changes at every level may not be desired; for instance, the client may not want to see a change to a Borrower's outstanding loan count in the log when a new Loan is approved, but they do want to see changes due to consolidations. Managing rules about logging in these cases requires change handling classes to know about more of the structure than just one object, which can very quickly make a change-handling object VERY big, and VERY brittle.
• The requirements of your graph walker are probably more than you know; if your object graph includes backreferences or cross-references, the walker must know where it's been, and the simplest comprehensive way to do that is to keep a list of objects it's processed, and check the current object against those it's handled before processing it (making anti-backtracking an N^2 operation). It must also not consider changes to objects in the graph that will not be persisted when you persist the top level (references that are not "cascaded"). NHibernate gives you the ability to plug into its own graph-walker and abide by the cascade rukles in your mappings, which helps, but if you're using a roll-your-own DAL, or you DO want to log changes to objects that NHibernate won't cascade to, you're going to have to set this all up yourself.
• A piece of logic in a handler may make a change that requires an update to a "parent" object (updating a calculated field, perhaps). Now, you have to go back and re-evaluate the changed object if the change is of interest to another piece of the change handling logic.
• If you have logic that requires creation and persistence of a new object, you must do one of two things; attach the new object to the graph somewhere (where it may or may not be picked up by the walker), or persist the new object in its own transaction (if you're using an ORM, the object CANNOT reference an object from the other graph with a "cascade" setting that will cause it to be saved first).
• Finally, being highly reflective in both walking the graph and finding the "handlers" for a particular object, passing a complex tree into such a framework is a guaranteed speed bump in your application.

I think you'll save yourself a lot of headaches if you skip the "change handler" reflective pattern, and include the creation of audit logs or any pre-persistence logic in the "unit of work" you're performing up at the business layer, through a set of "audit loggers". This allows the logic making the changes to employ an algorithm selection pattern such as Command or Strategy to tell your audit framework exactly what kind of change is happening, so it can pick the logger that will produce the required logging messages.