`ActionFilter`s and the like are passed a context object from which they can get various values left by the controller. One such example is the ViewBag, which the filter can inspect and alter after the controller has finished with it, but before the view gets it. Some applications use this to pass values to the filter ([see this example](http://stackoverflow.com/questions/18209735/how-do-i-pass-variables-to-a-custom-actionfilter-in-asp-net-mvc-app)).
This seems like an unintended use of the `ViewBag`, and it clutters the `ViewBag` with non-view-related items which may have naming conflicts. It also causes the system to pass values to the `View` that it does not need, which may have memory and performance implications.
It would be nice if there was a dedicated method for passing values to filters. There are numerous scenarios in which a filter may wish to access values from within a controller - values that are not compile-time constants, and so cannot be passed into the filter's constructor. For example, a method may wish to make an internal variable available to logging filters, such as the ID of the user making the request.
The simplest way to implement this would probably be a container (a `dynamic`, or some sort of key-value store like `Exception.Data`) accessible from within the controller that is included as part of the `ControllerContext` and passed into filters.
This seems like an unintended use of the `ViewBag`, and it clutters the `ViewBag` with non-view-related items which may have naming conflicts. It also causes the system to pass values to the `View` that it does not need, which may have memory and performance implications.
It would be nice if there was a dedicated method for passing values to filters. There are numerous scenarios in which a filter may wish to access values from within a controller - values that are not compile-time constants, and so cannot be passed into the filter's constructor. For example, a method may wish to make an internal variable available to logging filters, such as the ID of the user making the request.
The simplest way to implement this would probably be a container (a `dynamic`, or some sort of key-value store like `Exception.Data`) accessible from within the controller that is included as part of the `ControllerContext` and passed into filters.