hint for audit log approach

Question

Hello! 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

Perhaps you can implement the observer pattern, however, since .net implements this pattern implicitly (with events) i think there will not be much added value.

Perhaps you can save the "orginal" objetcs and compare them with the modified objects when time is right (perhaps using reflection) and find out what properties have changed and what their new value is. However, note that you cannot make deepcopies of objects in .net (except if you can serialize the objects), so keep that in mind for this solution

Answer 2

Have you checked out the Logging Application Block of the Microsoft Enterprise Library?

Answer 3

Either you need to keep the original data around in your object or pull it from the database for logging before the update.

I've seen this implemented in the data layer, either in stored procedures or triggers, but never in the domain layer.

Edit: A 2 part example of using database triggers to log history is found here: http://www.4guysfromrolla.com/webtech/041807-1.shtml There seems to lots of good discussion on the pros/cons of this technique. I hope that helps.

Answer 4

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.