No MVC, qual é a diferença entre controlador e roteador?

Eles significam a mesma coisa (anexar URLs a ações ou ações a URLs) ou há alguma diferença que esteja faltando?

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

Roteador:

O roteamento é o processo de obter um ponto de extremidade do URI (a parte do URI que vem após a URL base) e decompor em parâmetros para determinar qual módulo, controlador e ação desse controlador deve receber a solicitação.

Controlador:

O controlador implementa um padrão »do controlador, no qual todas as solicitações são interceptadas pelo controlador e despachadas para os controladores de ação individuais com base na URL solicitada (que é a solicitação de roteamento do roteador).

Um controlador de front-end deve colaborar com um roteador e um expedidor para decidir, com base na solicitação (HTTP) contra o aplicativo, que ação concreta deve ser executada e, em seguida, despacha-a.

Dependendo de como detalhou um projeto é, alguns Controlador s trabalho sem Router s e eles fazem o encaminhamento de seu próprio ou o encaminhamento está implícita no projeto como o pedido é processado.

Alguns Dispatcher s também passar um Pedido de objeto para o despachado métodos de ação . Os Métodos de Ação então decompõem a Solicitação em parte, para que até as ações do Controlador ainda possam fazer algum roteamento com base na Solicitação. Um exemplo típico disso é o caso em que uma estrutura oferece um redirecionamento como resposta. Isso também mostra como o roteador e o controlador estão relacionados ou próximos .

A diferença normalmente desenhada aqui é que o roteamento cuida ou ajuda a identificar qual método de ação executar e o controlador é responsável por fornecer essa ação, mas ambos tratam da solicitação.

Como você pode ver, as diferenças entre roteador e controlador podem variar bastante entre implementações e estruturas. No final, a aplicação concreta exige que um determinado nível de abstração seja útil ou não.

No entanto, pelos termos, eu diria que o Controller está em um papel mais alto no aplicativo geral. É aqui que a ação vai, por assim dizer.

A rota mapeia uma URL para um controlador, que é a ação. Às vezes, os papéis não são realmente separados muito bem, dependendo da estrutura.

Os roteadores fazem parte da camada do controlador. O mecanismo de processamento do roteador é uma substituição do padrão Front Controller da velha escola (a grande opção no index.php).

Em uma estrutura moderna, um roteador define uma conexão direta entre um "tipo" de possíveis solicitações e seu processador. Por outro lado, um controlador obtém apenas informações de identificação e analisa esses dados em seu próprio contexto.

Simplesmente, um roteador realiza uma jornada pelo aplicativo, geralmente com base em entradas externas, como variáveis ​​GET ou POST.

No entanto, um roteador não faz parte de um MVC; várias estruturas MVC e HMVC usam roteadores, mas isso não os vincula ao padrão do MVC.

Além disso, várias implementações anteriores do MVC que eu vi, na verdade, se baseavam na separação de ações baseada em arquivo com um arquivo por controlador para acessar controladores separados. Isso serve muito melhor ao aplicativo, porque, por ter controladores magros, com modelos mais robustos, você nunca precisa rolar para um método específico no controlador e, portanto, pode acessar a lógica em um único local (o modelo), permitindo a composição comportamentos.

O roteador pega o

solicitação

e decide quais métodos de controlador / controlador manipularão a solicitação.

O controlador aceita os pedidos e lida com isso!

Agora também criei um controlador que divide o URL e usa a primeira parte após o URL base como controlador e a segunda parte como ação. Isso carrega um arquivo correspondente ao controlador e um método nesse arquivo correspondente à ação.

Este não é realmente um controlador (no que diz respeito ao MVC), faz parte do roteamento.

Por exemplo, pegue a uri [GET]: example.com/article/view/123 O roteador MVC analisará a uri e encontrará os seguintes segmentos

article view 123 Por padrão, a maioria dos roteadores agora instanciava o articleController e chamava seu método de view passando 123 como parâmetro. (Você também pode ter algum método getUriSegment (segmentIdx), que é uma opção de design para sua estrutura.)

O ArticleController teria um método de exibição com um parâmetro $ articleId. Esse método provavelmente faria algo como: obter o artigo especificado (de um banco de dados por meio de um modelo, por exemplo) e depois exibi-lo (provavelmente retornando uma visualização que recebeu o artigo retornado pelo modelo