I have a C# MVC application. One of the requirements of the application is to maintain an audit log of everything that happens to a particular 'entity' page. To make the example concrete, lets say there is a customer page, with sub entities like addresses and phone numbers.
I have an audit service that logs a particular action type, so in the GET action to display the customer page, I log an 'access' audit record. Similarly, when a user creates a customer, or updates a customer, I have a audit logging event for that as well in the respective controller method.
The design issue I am encountering and would like some advice on is how to handle the 'access' audit event. When the user first lands on the page I capture and log the access audit event I am looking for. However, when the user interacts with the page and say, adds an address or a phone number to the demographic table, I get another access audit recorded because after the user adds a sub-entity record to the parent entity (the customer in this example) a redirect is fired back to the customer's GET method and another access audit record is logged.
Therefore in short period of time, I can have multiple accesses to the same page, multiple times. This goes beyond the intent of the access audit record. I simply wish to show that the 'customer' page was accessed by the user at a particular time and date. But to log the access every time a Post-Redirect-Get action occurs on the page is not only redundant, but unnecessary. What I want is an audit of the access, not necessarily a page view (which is what I have now).
What would be a better approach to this? I hope I have explained the design issue appropriately. I could just not worry about it and when I go to display the audit log to an admin, I can filter out the 'access' records and limit it to a time-frame, i.e. only show an access record if the times are more than say 10 minutes apart. But I feel like there may be a better solution that I'm not seeing.
Best Answer
Your approach to log every get request even if the information with the current requirements is redundant could potentially prove valuable in the future if requirements change. In that case you simply change your log-filter.
Otherwise the audit service seems like a good place to filter events before storing them. This service could maintain an in-memory list of recent requests and only persist events to the data store if necessary.