views:

2310

answers:

7

I need to implement an audit trail for Add/Edit/Delete on my objects,I'm using an ORM (XPO) for defining my objects etc. I implemented an audit trail object that is triggered on

  1. OnSaving
  2. OnDeleting

Of the base object, and I store the changes in Audit-AuditTrail (Mast-Det) table, for field changes. etc. using some method services called.

How do you implement audit trail in you OOP code? Please share your insights? Any patterns etc? Best practices etc? Another thing is that how to disable audit when running unit test,since I don't need to audit them but since base object has the code.

Changes to object (edit/add/del) and what field changes need to be audited

A: 

I know this doesn't answer your question, but for the record, I prefer to handle this type of auditing logic in the database.

Galwegian
+4  A: 

Database triggers are the preferred way to go here, if you can.

However, recently I had to do this in client-side code and I ended up writing a class that created a deep (value) copy of the object when it was opened for editing, compared the two objects at save time (using ToString() only) and wrote any changes to an audit table.

Edit: I had an [Audit] attribute on each property I wanted to consider auditable and used reflection to find them, making the method non-specific to the objects being audited.

I've voted this answer up, but one thing to watch out for when using database triggers is transaction brackets. You sometimes want to audit an event even when an error occurs and the transaction is rolled back.
Andrew
A: 

I come more from the SW side that the DB side, if you create a set of DAOs (Data access objects) that you use for your interaction with the database. I would then insert the audit functionality into the respective functions in the DAOs that need to be trailed.

The database trigger solution is also feasible, it depends where you like to put your functionality, in the DB or in the code

There are a lot of ORM (Object relational Mapping) tools out there that create the DAO layer for you.

Harald Scheirich
+2  A: 

I don't know if it will fit seamlessly with your ORM, but i used Point-in-Time database design for an ERP application and really recommend it. You automatically get History and Audit from this architecture, as well as other benefits.

Constantin
A: 

Thanks for replies

abmv
A: 

We've implemented a similar solution, using AOP (aspectJ implementation). Using this particular points can be captured and specific operations can be performed.

This can be plugged in and plugged off when we like.

If you really want to do it in the app layer, i would suggest this.

Hope it helps..

Satya
A: 

I've done this in Hibernate (another ORM) using an Interceptor for the Session. That way the audit code is seperate from your code.

Aidos