1

So I have been reading some comments on StackOverlow, saying that you shouldn't put business logic in a custom ActionFilterAttribute because it is considered meta data.

For example accessing a repository and doing some checks, and processing accordingly within your custom attribute (bad).

Firstly I am not sure how much I agree with this because alot of the framework Filters (Authenticate) etc, do business logic - the main difference it is mostly within the scope of the controller only i.e. only accessing controller values, route data etc.

So my question is, when you do need to use an ActionFilter to flag individual Actions for additional logic/processing, where do you put the logic?

Thanks for the input/

shenku
  • 11,969
  • 12
  • 64
  • 118
  • Can you provide a link to places that have defined doing the checks described in your second paragraph as bad? Actionfilters are built for these kinds of cross cutting concerns. – Chad Ruppert Nov 26 '12 at 03:46
  • http://stackoverflow.com/a/6131160/148998 – shenku Nov 26 '12 at 04:04
  • See my answer here: http://stackoverflow.com/questions/13223133/mvc3-release-strategy/13362059#13362059 after reading my answer to your question. – Chad Ruppert Nov 26 '12 at 04:11

1 Answers1

1

There is nothing wrong with using actionfilters to do some business logic. Typically this is how you implement those cross cutting concerns like logging, security (as you pointed out).

Their purpose is all in their name. Filters for your Actions. Either incoming actions, or outgoing modifications to your data to be output.

What you need to beware is putting behaviors that modify business data and persist the changes in actionfilters. These kinds of things are counter intuitive to the next developer to see your code. They don't filter anything, they change the state of the overall system, which is what Actions(Commands) are for.

Chad Ruppert
  • 3,650
  • 1
  • 19
  • 19