CSLA BO audit

kyle.l.watson@gmail.com posted on Friday, January 16, 2009

Whats the easiest way to audit a BO without breaking the single responsibility rule? I was hoping for a very standardized way to do this.

whelzer replied on Saturday, January 17, 2009

Easiest or best? What exactly are you trying to audit. Search this forum for "Auditing", there are 3 very good recent posts about Auditing, you've a few options when it comes to auditing...

We took (imho) the best approach and let our DB take of it. Your "Customer" object should be concerned solely with customer issues/behaviour. Auditing is a side issue (or is for us anyway).

We shadow our normal tables eg tblCustomers & tblCustomersAudit - the "Audit" table has a few extra columns (Timestamp, user, etc). in _spCustomerUpdate - we merely update tblCustomers and insert to tblCustomersAudit.

We then have a fairly snazzy command oject that emails manangement of certain changes to certain properties and the above makes this straightforward.

Hope that helps.

kyle.l.watson@gmail.com replied on Monday, January 19, 2009

Thanks, I definitely looked at some of the auditing threads which gives me a good idea of how to implement auditing. Thanks.

rsbaker0 replied on Sunday, January 18, 2009

I opted for having all my BO's derive from a common base class, which then derives from BusinessBase<T>.

The common base class implements a virtual OnPropertyChanging() method (the equivalent of which may be in CSLA by now but was not in 2.1). My code generated properties call this in the property setter and pass in the original and new value of the property (as well as the property name).

This makes auditing easy without some of the space overhead of maintaining duplicate storage for every property (like some of the managed field implementations suggest). Only the changed values have storage overhead.