What's the best approach to write chronology entries on certain actions in ASP.NET Core MVC?

Question

I'm working on a software product that entails users opening up a case and taking actions to process the case, changing the status, creating tasks, etc. I'd like to provide a history of the actions taken to process the case in the form of chronology entries. I'm trying to avoid having my controllers get too fat and was trying to use an approach where I leverage action filters and decorate the actions that need a chronology entry, however I was trying to have the chronology entries relate back to the Case/CaseID.

I don't currently have a CaseID stored anywhere that the action filters could use, the caseID is typically a parameter to the MVC action along with any other needed processing data. So my questions are:

1. Should I even be using action filters for this, or should I just create a service class that handles writing chronology entries to the database and make calls to the at the end of each action method after the action has completed successfully?

2. If action filters are the right approach what is the best practice for making the CaseID available to the action filter? [ChronologyActionFilterFactory(ActionTitle = nameof(TaskChronologyActionsEnum.TaskCreated), ActionNotes = "")] I can't make the CaseID available in the decoration because it typically has a local scope for the action method. Some appproaches I thought are to populate a session variable when the case is opened, set a variable at the controller level, or set a variable at the base controller level.

Looking for some recommendations no what the best approach would be to implement this sort of functionality.

Answer 1

I'm trying to avoid having my controllers get too fat

That's admirable, but if you are replacing a 1-line logging method in the body of each Action method with a 1-line ActionFilter attribute, then you aren't reducing the fatness of the controllers at all. As you've noticed, the problem with ActionFilters is that you don't have access to the full range of variables that are entering the method at runtime. Everything else you might do to push the CaseId to the ActionFilter is going to be more complex than just adding the logging function to each Action method body.