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.

  • 6
    Questions to ask yourself: Is this chronology feature/requirement a direct result of you using asp.net core? Or, would the feature/requirement still exist even if you switched to another technology? If the latter, then you probably shouldn't couple it to an asp.net core feature.
    – MetaFight
    Oct 15, 2018 at 15:48
  • Even if you use action filters, you'd probably still need some kind of service, so I'd start with the service.
    – Dan Wilson
    Oct 17, 2018 at 10:52

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.