In MVC, what is the difference between controller and router?

Question

Do they mean the same thing (attaching URLs to actions, or actions to URLs) or is there any difference I'm missing?

Example: http://github.com/dannyvankooten/PHP-Router vs. http://konstrukt.dk

Answer 1

Router:

Routing is the process of taking a URI endpoint (that part of the URI which comes after the base URL) and decomposing it into parameters to determine which module, controller, and action of that controller should receive the request.

Controller:

Controller implements a »Controller pattern, in which all requests are intercepted by controller and dispatched to individual Action Controllers based on the URL requested(that is routing request from Router).

Answer 2

The route maps a URL to a controller, which is the action. Sometimes the roles are not really separated very well depending on the framework.

Answer 3

A Frontend-Controller should collaborate with a Router and a Dispatcher to decide based on the (HTTP) request against the application which concrete Action has to be executed and then dispatches it.

Depending on how detailed a design is, some Controllers work without Routers and they do the routing their own or the routing is implicit in the design how the request is processed.

Some Dispatchers also pass a Request object to the dispatched action methods. Action-Methods then decompose themselves the Request in part so that even Controller actions still can do some routing based on the request. A typical example for this is the case when a framework offers to do a redirect as the response. This also shows how related or near Router and Controller are.

The difference that is normally drawn here is that the routing takes care of or helps with identifying which action method to execute and the controller then is responsible to provide this action but both handle the request.

As you can see, the differences between Router and Controller can vary greatly between implementations and frameworks. In the end, the concrete application has it's needs whether or not a certain level of abstraction is useful or stands in the way.

However from the terms I'd say that Controller is in a higher role in the overall application. This is where the action goes so to say.

Answer 4

Routers are part of the controller layer. The router processing mechanism is a replacement of the old school Front Controller pattern (the big switch in the entry point).

In a modern framework a router defines a direct connection between a "kind" of possible requests and its processor. By contrast, a controller gets just identifying information, and parses this data in its own context.

Answer 5

Quite simply a router works out a journey through the application, usually based upon external input such as GET or POST variables.

A Router is not however any part of an MVC, several MVC and HMVC frameworks use routers, but this does not bind them to the pattern of MVC.

Additionally several early implementations of MVC I have seen actually relied on file-based separation of actions with one file per controller for accessing separate controllers. This serves the application much better, because by having skinny controllers, with more robust models, you never have to scroll to a particular method in the controller, and you can therefore access the logic in one place (the model), allowing you to composite behaviours.

Answer 6

The router takes the

request

and decides which controller/controller methods will handle the request.

The controller accepts the requests and handles it!

Now I've also made controller that splits the url and uses the first part after the base url as controller and second part as action. This loads a file corresponding with the controller and a method within that file corresponding with the action.

This isn't really a controller (as far as MVC is concerned) it is part of the routing.

For example take the [GET] uri: example.com/article/view/123 The MVC router will parse the uri and find the following segments

article view 123 By default most routers would now instantiate the articleController and call its view method passing in 123 as a parameter. (You could alternatively have some getUriSegment(segmentIdx) method, that's a design choice for your framework.)

The ArticleController would have a view method with an $articleId parameter. This method would probably do something like: get the specified article (from a db via a model for example) and then display it (probably by returning a view which has been given the article returned by the model