logic before dispatcher + controller?

Question

I believe for a typical MVC web application the router / dispatcher routine is used to decide which controller is loaded based primarily on the area requested in the url by the user.

However, in addition to checking the url query string, I also like to use the dispatcher to check whether the user is currently logged in or not to decide which controller is loaded. For example if they are logged in and request the login page, the dispatcher would load their account instead.

But is this a fairly non-standard design? Would it violate MVC in any way? I only ask as the examples I've read through this weekend have had no major calculations performed before the dispatcher routine, and commonly check whether the user is logged in or not per controller, and then redirect where necessary.

But to me it seems odd to redirect a logged in user from the login area to account area if you could just load the account controller in the first place?

I hope I've explained my consternation well enough, but could anyone offer some details on how they handle logged in users, and similar session data?

Answer 1

This seems to be fair requirement, and can be achieved using a intercepting filter. The request header can be inspected and flagged as an attempt to login, or mark as a malicious attempt. Alternatively the dispatcher can delegate this to a different controller which can do the same and redirect the request appropriately. MVC is all about segregation of intelligence in the application. This case falls under sanity check (technical requriement than a business requirement).

Answer 2

The current MVC framework that I'm using has pre dispatched and post dispatched features. I normally place the login checking in the predispatch process rather than directly putting it in the dispatcher. Also, an authentication class may do the job for you.