Short answer is: use both. Intercepting Filter and Front Controller are typically used in combination. IMO, the real question is how to separate the concerns of each in my web application.
This is a common question I encounter.
Sometimes, when I need to implement a request/response handling functionality in the presentation tier,
choosing between processing in Intercepting Filter and Front Controller becomes a matter of preference. Both patterns offer a way to centralize control of request/response processing. However, there are some key differences in how you assign responsibilities to each.
- I use Intercepting Filter when I want loosely-coupled pre and post processors for request/response handling.
Intercepting Filters offer pluggability and configurability so that I can add/remove filters non-intrusively (declaratively). Filters are ideal if the operations they perform are well-encapsulated and discrete so that I can plug and play as I want.
- For all other common request processing, a Front Controller is the way to go for me. Front Controller avoids duplication of code in multiple views. Typically, once I implement a Front Controller, I pretty much want to leave it alone as much as possible. Over time, if I start seeing lots of conditional switching (if-then-else or case/switch) in my Front Controller, then I might refactor conditional logic using Intercepting Filters or delegate the conditional processing to helpers using the Command and Controller Strategy [see Front Controller pattern] implementing a Command [GoF] based services layer.
Bottomline: I want my Front Controllers to be straightforward, simple and easy to maintain, and my Intercepting Filters to be loosely-coupled, pluggable and stateless.
What do you think?