Object Level Audit Trail

glenntoy posted on Tuesday, December 12, 2006

In most cases audit trail is implemented in DB using triggers/stored procedures upon inserting/updating/deleting the data in the table. However has anyone thought of doing object level audit trail in CSLA version 2.0? Again, I want to hear your insights/theory on how to achieve object level audit trail.

Thanks,
Glenn

ajj3085 replied on Tuesday, December 12, 2006

Glenn, are you trying to do auditing or locking?  Those are distinct tasks, and have nothing to do with each other usually.

glenntoy replied on Tuesday, December 12, 2006

Sorry Andy, what I mean is Audit Trail. I got mixed up with my previous post. I'll try to edit the main post. What I'm trying to do here is to create proof of concept of object level audit trail.

Norty replied on Wednesday, December 13, 2006

Since we do not always have a DB where we can implement triggers, we do not use them.  To date we have only implemented 1 project using CSLA, but this is about to change.  In the past we have always maintained a list of changes in the app, which get written to the DataStore when the object is persisted.

I am currently considdering an intermediate library (myCSLA) with public classes that inherit from CSLA.  Apps will then inherit from myCSLA.  At this point, the only class that will do anything meaningfull is myBusinessBase.  It will include the following code (or something like it).  Then in the DP_Update we would persist the list to the DataStore.

Private Structure AuditLog

   Dim PropertyName As String

   Dim SavedValue As Object

   Dim CurrentValue As Object

End Structure

Private mAudit As New List(Of AuditLog)

Private Sub SetProperty(Of T)(ByVal PropertyName As String, ByRef OldValue As T, ByVal NewValue As T)

   If Me.IsNew Then Exit Sub

   If OldValue.Equals(NewValue) Then Exit Sub

   Dim blnExists As Boolean = False

   For Each itm As AuditLog In mAudit

      If itm.PropertyName = PropertyName Then

         blnExists = True

         If itm.SavedValue.Equals(NewValue) Then

            mAudit.Remove(itm)

         Else

            itm.CurrentValue = NewValue

         End If

         Exit For

      End If

Next

If Not blnExists Then

   Dim itm As New AuditLog

   itm.PropertyName = PropertyName

   itm.SavedValue = OldValue

   itm.CurrentValue = NewValue

   mAudit.Add(itm)

End If

OldValue = NewValue

PropertyHasChanged(PropertyName)

End Sub

ajj3085 replied on Wednesday, December 13, 2006

No problem, just needed to know what you were really seeking suggestions on.

If you have a database which supports stored procedures or triggers, those are your best bet.  You don't need to do anything in the objects to create an audit history.  You can also add auditing to an existing database without worrying about breaking your application in some cases.

You likely would need some BOs that can read an intereprate that audit trail, but thats a seperate use case, so i wouldn't put any code in your existing BOs. 

Now if your db doesn't support stored procedures or triggers,  you may have to have your BOs create the audit trail.  But this should be handled by a BO who's only job it is to create the audit trail, if possible.

HTH
Andy