Application-wide audit of all dataportal calls (well, only the ones that modify data)

[vijaygill]

Hi,

I am required to implement logging of every datapoirtal call which leads to changing of data. Only changed properties need to be logged and a collection of those can then be saved as JSON in the logs along with the user identity.

All the DataPortal operations are server side, so logging is to be done at one place.

Thanks.

[rockfordlhotka]

Hi @vijaygill,

This should be possible with some work.

The server-side data portal has hooks where you can implement logging. The Using CSLA 4 book on the data portal covers these hooks up through CSLA 5. There are some changes in CSLA 6, though your options are similar. So it should be pretty easy to choose one of the options and implement logging.

Actually knowing which properties are changed is a little harder. The default implementation of the field manager doesn't maintain the original value retrieved from the database (due to size in memory and over the network).

One way to know for sure which properties have been changed is to maintain that original value so you can compare the current value to the original. The cost of this is memory and data over the wire.

The other way to know within reason that properties have changed is to compare the current value in the object to the current value in the database. This has the cost of pulling the data from the db for comparison and isn't a perfect answer, b/c someone else could have changed the db in the meantime.

Another way to know within reason is to store a hash code of the original value in the field manager, and then compare that hash to a hash of the current value to see if they are different (for your logging). Hash codes aren't guaranteed to be unique, so there's a non-zero chance of a changed property not being detected. You'd also be maintaining and transporting over the network an int (hash value) for each property, which is a small cost.

[rockfordlhotka]

Oh, I see what you are after.

FieldManager is interface-based with the intent that if you wanted to implement a different IFieldManager that did track the original value, you could do such a thing. Then your FieldManager.IsDirty could report based on comparing to the original value.

[hurcane]

We tried implementing the necessary interfaces, based on an old example from Jason Bock. However, that implementation carried a copy of every value. The sample used hashes for strings, but we needed the full original value. We found that implementation was pretty heavy from a memory perspective. This technique with the dictionary is much more lightweight.

[hurcane]

My main reason for posting that code was because the OP was making a request that we have had for a while now, and I thought it might be helpful when the need arises to log the original value.

[rockfordlhotka]

I like your approach for sure!

I still think there should be some way to create a custom FieldManager that accomplishes that goal without a high cost, though maybe I'm wrong. Something that only copies the original value on first change of the property?

It doesn't really matter, in that you have a good solution.

[vijaygill]

Thank you @hurcane and @rockfordlhotka for such invaluable discussion and insight into this.