Question

I’m currently developing an ASP.NET Human Resources System. I’m using a layered architecture with Web Client Software Factory, which is based on MVP pattern. ORM is NHibernate. And I need to implement an Audit Log module. I’ve read a lot about different approaches. Most of them describe how to track date, timastamp and identity of person who made that change, but no one could tell me about that one: how to track changes of any property in my Domain layer? I don’t need any rollback capability, I need only Log with: who, when and what property of what object was changed, old value and new value of that property.

I can’t decide where to put the handler of this changes. Fowler pointed an Audit Log in setter method of properties, but I still want to keep my domain classes simple POCO`s. Maybe there is some other approach?

Answer 1

I had to do this a few years back for an HR system as well. I accomplished it having all my ‘fields’ implement a template (generic):

Here is an example of the template I made trimmed down:

class DataField<T>
{
    public T Current { get; set; }
    public T Original { get; set; }
    // stores the field name as a nice textual readable representation.
    // would default to property name if not defined.
    public string FieldName { get; set; }
    public bool Modified
    {
        get { return !(Current.Equals(Original));
    }

    public DataField(T value)
    {
        Original = Current = value;
    }

    public DataField(T value, T fieldName)
    {
        Original = Current = value;
        FieldName = fieldName;
    }
}

The interesting part about it that made auditting easy was that each object could produce it’s own audit log. I could take any object that could have x number of these ‘fields’ and call the GetAudit on it and it would return me an audit object with all the changes to the class showing the field name, old val, new val etc.. Each ‘DataField’ would implement a method to return an audit object. For strings, double, ints etc it was pretty much baked in but if you used custom objects you could write the audit implementation for them that just had to return a Audit object.

So in a typical form at the end I would have all the data stored in one object that had all these types of fields. I would then do an update and call the GetAudit method which would also be written to an audit table as well.

I could easily tell if anything had changed in the form even if they had to go through multiple pages etc.

Undo’s were really easy on a field by field, section by section or the entire object level as well.

Little foggy on the exact details as I haven’t touched the code in a long time but that was the gist of it. Hope that helps.