php5minutes 7 – O C do MVC – Controller

Nesse podcast de No 7 o assunto é o controller do MVC.
O controlador do MVC é a parte desse padrão de desenvolvimento que é responsável pelo processamento das requisições realizadas pelo cliente, ou seja, o usuario do sistema.
Como já foi falado de Model e View, esse também é a conclusão da série sobre MVC, e por causa disso, ele contém alguns prós e contras de se programar utilizando esse conceito.

O que temos então, nesse php5minutes sobre controller, pode ser visto em resumo, na lista aqui ó, na sequencia em que ocorrem/precisam ser entendidos os itens:

url’s amigaveis.

bootstrap.

carrega o front controller.

resolve de rota da requisição.

requisita o controller que vai atender a requisição.

executa a ação/ processa a requisição.

Define os dados para a view.

Define a view que será utilizada.

renderiza a view no dispositivo que requisitou a ação(Se for uma view do banco e tiver saldo, faz o cliente feliz. Se for do facebook e tiver mais algum convite do mafia wars, o cara fica triste).

[podcast]http://ianntech.com.br/wp-content/plugins/download-monitor/download.php?id=24[/podcast]

Link para download em Zip do php5minutes 7 – O C do MVC – Controller

9 thoughts on “php5minutes 7 – O C do MVC – Controller

  1. Palmas!!! Palmas!! Palmas!!

    Esse foi o melhor. Muito bem explicado. Foi super fácil de entender.

    Parabéns. O podcast sobre o MVC, foi sensacional.

    Uma coisa que ainda me deixa com uma pulga atrás da orelha é:
    Regra de Negócio é no Controller ou no Model?

    Já vi muitos dizerem que é no Model e outros no Controller.

    Falô!

    • Opa, legal que voce gostou, mas quanto a sua duvida eu tenho uma forma de pensar e aqui vai ela.
      Digamos que voce tem um objeto que é uma cadeira, e precisa move-la… na vida real, a cadeira se move sozinha ou alguem a move?!(momento filosofico de gordo que so pensa em ficar sentado. Se fosse atleta diria algo como uma bola de basquete).
      Eu imagino que sua resposta seja que alguem precisa move-la e se o caso for esse… transporte seu pensamento para uma sistema.
      Digamos voce tem uma tabela que guarda modelos de cadeira em um sistema que diz onde elas estao no estoque… o Model que representa um registro de uma cadeira, deve saber se colocar no estoque? ou alguem, um controller, o colocaria na posicao correta no estoque?
      Pra mim, colocar a cadeira em uma posicao no estoque é uma função do controller, pois isto é uma funcionalidade do sistema, que de forma alguma tem a ver com a cadeira. Tem sim a ver com o que o sistema precisa controlar, concorda?
      Indo um pouco mais longe, o mesmo objeto cadeira foi usado em um outro sistema de vendas que so precisa saber que ela existe e suas especificações… e ai, que voce faz, mantem dois modelos de cadeira ou deixa la perdido o metodo que sabe move-la, mesmo que nunca seja usado?
      …ou na implementacao desse novo sistema cria um controller que cuida da venda e aproveita o mesmo objeto… mantendo somente uma versao do codigo?

  2. Não não, rs… sem regras de negócio em Controllers. Eles devem ser quase tão burros quanto VIEWs rs. Devem possuir inteligência suficiente somente para gerenciar as requisições, saber o que invocar no Model e redirecionar para as Views, nada mais. Regras de negócio nesta camada não podem ser reaproveitadas.

    Concentre-se no Model para isso e utilize um bom modelo de domínio (Domain Driven Design). Recomendo alguns livros que iram ajudar a compreender melhor este conceitos: Domain-Driven Design by Eric Evans, Patterns of Enterprise Application Architecture by Martin Fowler e Design Patterns by Gang of Four. Bom divertimento rs.

    Aliás, parabens pela sua iniciativa e pela troca de informações!
    Abraços!

    • Oi Rodolfo, seu comentário foi super legal para a discussão, mas meu ponto de vista foi outro… e assumo, que olhando pelo seu ponto de vista, pensando no DDD, faz muito e todo o sentido.
      Irei escrever um artigo sobre o DDD e o MVC como material atrelado a este podcast, mas ele não esta, de todo errado.
      E DDD merece um cast ou mais só sobre ele.
      Ainda vejo uma separação entre regras da aplicação e regras do objeto, isso sim, mas existem várias maneiras de organizar-las.
      Abraços e muito obrigado mesmo.
      Esse espaço aqui é pra discussão e é de todos, só não vale troll mode on. 😉

  3. Muito bom os podcasts, descobri-os hoje e fiquei bem feliz, conteúdo de primeira, bem explicado e tals. Eu acho que MVC e design patterns são assuntos delicados para se dizer “é assim” ou “é assado”. Muitos pegam a ideia original e a adaptam para suas necessidades chamando essa ideia com o mesmo nome da ideia original.
    A principal prova disso é sobre o padrão MVC em si. A maneira de se programar para desktop é muito diferente da utilizada em frameworks de PHP por exempĺo. Além do mais, mesmo para desktop, existem mais que um “modelo MVC”, como os mostrados neste artigo:
    http://www.oracle.com/technetwork/articles/javase/index-142890.html#1

    Acredito que o “MVC Modificado”, mencionado no artigo é o mais parecido com o MVC que utilizamos nos principais frameworks para PHP, mas ainda sim não é igual, já que a request é feita para um controller no nosso caso. No MVC original, o model dispará eventos que são capturados pela view, não fica tudo sendo controlado pelo controller.
    Eu já penso o seguinte: MVC pode ser adaptado para todas as situações, mas nem sempre é o mais adequado, nem sempre é o melhor para se usar. Digo isso me baseando no MVC original, já que o MVC que estamos ouvindo nestes podcasts são uma adaptação do MVC.
    Por isso eu penso que ditar se a regra de negócio fica no modelo ou no controller depende muito do programador e da funcionalidade do sistema.

    Penso assim:
    Controller vai controllar qual view será renderizada e determinará quais parametros serão passados para a view E como eles serão passados (geralmente por um método set, assign, registry e tals). Então deixar a regra de negócio no controller como no exemplo, deixar o controller saber onde colocar a cadeira, “prende” tanto model quanto view a este controller. Por que prende? O controller está intimamente ligado a view decidindo quais dados ela receberá e como receberá e ainda tem as funções que “afetam” dados no model, no sentido de ter a regra de negócio. Se eu decidir passar esta aplicação para desktop, terei que reescrever toda a minha regra de negócio, já que terei de reescrever o controller para poder falar com o meu novo tipo de view.
    Já se minha regra de negócio ficar no modelo e o meu controller esperar apenas certos tipos de dados da view, tratálos e repassálos para o modelo para que ele faça o “negócio”, terei apenas que refazer minha view para a versão desktop, cuidando apenas para que minha view passe os dados seguindo algum “protocolo”.

    Obviamente, tudo isso que eu falei pode ser contestato facilmente com o seguinte argumento: mas se minha regra de negócio ficar no controller, posso apenas fazer com que minha nova view envie os dados da mesma maneira, parecendo ao controller e ao modelo que continuo trabalhando em um ambiente web. Para isso, o tratamento dos dados ficaria na view, deixando que ela se preocupasse exatamente em como mandar os dados…
    Enfim, isto é programação e existem milhões de maneiras de se fazer a mesma coisa. Eu particularmente prefiro criar subcamadas no modelo para isso: classes entidade, DAO, classes com a própria regra de negócio…
    O que vale, é atender aos requisitos do sistema: precisa funcionar com diferentes tipos de view? Qual a lógica que utilizarei no meu sistema? Se a maneira que tu está estruturando o seu MVC atende aos requisitos finais do seus sistema, na minha opinião está valendo.
    Espero ter contribuído em algo com esse comentário atrasado e imenso.
    Abraço

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s