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
Ivan Rosolen
05/04/2010 — 03:57
Tem mais do que 5 minutos!
Ficou muito bom esse! O melhor do MVC!
Abraços
Wil
06/04/2010 — 17:32
Bem legal! ^^
Fábio S Ribeiro
06/04/2010 — 17:35
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ô!
Ivo Nascimento
06/04/2010 — 20:14
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?
Fábio S Ribeiro
07/04/2010 — 11:01
Entendi tudo… Vc tem razão..
Agora está claro!
Muito obrigado…..
Rodolfo Bottossi
08/04/2010 — 07:37
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!
Ivo Nascimento
08/04/2010 — 09:57
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. 😉
Thiago Marinho
28/05/2010 — 11:18
Ola Ivo!
Mto legal o podcast! =)
é o 3º q escuto mto bom mesmo!
vlw!
Danilo Morães
28/10/2010 — 20:49
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