Essa é uma pergunta que eu me fiz pelo menos umas 300x durante o ano de 2006. MVC é a sigla para Model-View-Controller, uma metodologia de design que divide o software em 3 partes.
- Model: parte responsável por manter o estado e a lógica da aplicação.
- View: parte responsável pela formatação das telas que são apresentadas as usuários.
- Controller: parte responsável pela controle do fluxo da aplicação.
Lindo, eu li isso em milhares de lugares diferentes, mas a pergunta persiste, What The Fuck Is That? Que negocio é esse de estado da aplicação? Ok, a parte das telas eu entendi, mas poxa, que raios é a lógica de negócio de uma aplicação? E como eu junto isso tudo?
Ontem todas estas minhas perguntas foram respondidas :)
- Model é a parte responsável pelos dados de uma aplicação. O model, como o nome já diz, é onde vou definir o modelo dos meus dados. Agora que eu sou uma pessoa chique, estou na moda e programo orientado a objeto (ok, entrei na moda atrasado, a moda agora é programação orientada a aspectos, mas logo logo eu chego lá) , então meus modelos são objetos. Cada modelo é uma classe, contendo seus atributos e métodos. Toda a parte que trata do dado é feita aqui. Tanto no que diz respeito a manutenção do estado da aplicação, quanto ao que diz respeito a lógica da aplicação, que são tratadas pelos meus métodos. Deve-se ficar claro que o modelo deve ser capaz de tratar de toda a lógica que o envolve e não apenas ser um guardador de valores. Se ele for capaz de tratar toda a lógica que o envolve, então depois poderá ser reutilizado em outro aplicativo.
- Sobre a view, creio que não preciso falar muito né? É a formatação da tela que será apresentada ao cliente. Aqui entra HTML, Flex, OpenLaszlo, etc. Já ia me esquecendo, tem mais coisa pra falar de view sim. Para gerar a interface que será apresentada para o usuário da aplicação, a view faz acesso direto às classes que foram definidas no model. Agora fica até obvio, se o view tem que apresentar meus dados aos usuários ele tem que ter acesso a estes dados.
- Controller é a parte da aplicação que vai receber as requisições do usuário. É ele quem vai determinar o fluxo da aplicação, ou seja, é ele quem vai dizer que métodos devem ser invocados para tratar determinada requisição. São os organizadores da aplicação, eles recebem uma requisição do usuário, interagem com o modelo adequado para o tratamento desta requisição e retornam, ao usuário, a view correspondente.
Estou aprendendo ainda, então se você já tem experiência com isso e estiver lendo alguma besteira, por favor me avise, assim como fez o Danilo Magrini e eu já corrigi os erros que ele apontou. Valeu Danilo.
A figura abaixo foi retirada do livro Agile Web Development With Rails e ilustra bem o modelo MVC.
Facil não? Só não entendo por que demorei tanto para aprender isso. Enfim, acho que o único texto que encontrei que explica isso direitinho foi o Agile.
O mais curioso de tudo é que eu sempre achei que MVC era uma ideia nova. Nova nada, MVC foi idealizado em 1979!!! E eu achando que MVC era pra web apenas. Trygve Reenskaug foi o cara que pensou no MVC, engraçado que o pessoal do desenvolvimento web só se voltou pro MVC muito tempo depois de quebrar a cabeça e fazer o sistema todo num bolo só (monolÃtico). O site oficial dele pode ser acessador por aqui.
29-12-2006 Ã s 06:54
Olá Alexandre,
Parabens pelo blog, boa sorte e continue sempre postanto.
Gostei de suas ideias, hoje em dia a popularização da linguagem Ruby é continua, eu tbm andei dando umas boa vasculhada na documentação =)
Um grande abraço
29-12-2006 Ã s 19:33
Parabens cara. Tou gostando da maneira como vc tem repassado seus estudos.
Continua nessa. Vou te mandar um material sobre MVC que andei lendo esses tempos.
Abraço.
2-01-2007 Ã s 10:28
Olá Alexandre,
parabéns pela iniciativa. Você colocou que gostaria de opiniões a respeito do que escreveu então resolvi fazer alguns comentários para discutirmos em cima. Encontrei algumas definições que ficaram vagas, vamos lá:
1) “MVC é uma metodologia de design que divide o software em 3 partes”
- não sei se pela simplicidade da sua definição, mas encontrei aqui a grande problemática existente no conceito MVC: Confundir MVC com Camadas. MVC na verdade não divide o software em 3 partes, MVC é somente uma das formas como suas camadas podem “conversar” ou integrar-se. O conjunto de componentes visuais da Sun para Java chamado Swing (que teoricamente deveria estar na camada de apresentação da sua aplicação) por si só já implementa MVC… na verdade não é um full MVC e sim um quase MVC hehehe foi dado o nome de Event Delegation. Mais informações aqui: http://java.sun.com/products/jfc/tsc/articles/architecture/
2) “Controller: parte responsável pela lógica de negócio da aplicação.”
Na verdade o bussines logic ou o chamado domÃnio faz parte do Model e não do Controller. O controller na verdade diz respeito ao application behavior, comportamento do sistema, que é quem vai receber as ações e disparar as atividade solicitadas. O controller, via de regra acessa funcionalidades da aplicação que estão encapsuladas no Model.
3) “Model… Toda a parte que trata do meu dado é feita aqui”
Legal, por isso mesmo que é aqui onde devemos colocar nossa logica de negócio. Isso é bom para evitarmos os tão utilizados TOs, VOs, DTOs que são objetos burros e dispensáveis para 99% dos sistemas, principalmente os “monolÃticos”.
4) “Sobre a view… se o view tem que apresentar meus dados aos usuários, é claro que ele tem que ter acesso ao local onde defini estes dados”
Bem, não entendi bem o que você quis dizer com “ter acesso ao local onde defini estes dados”. Na verdade o conceito MVC Model-2 implementa o pattern Observer e quem notifica o a view sobre alterações no domÃnio é o model e não o contrário. O problema maior está em implementar o pattern Observer em interfaces pobres como em aplicações web por isso temos algumas diferenças nesse ponto do modelo MVC quando implementado para o mundo web. Para contornar esse situação vários e vários frameworks têm tentado chegar a um ponto bom de implementação, desde o FormBeam do Struts até Typestry, JSF e outros.
um abraço.
Danilo G. Magrini
3-01-2007 Ã s 09:54
Opa, blz Danilo?
Obrigado por contribuir com o blog, é essa a intenção, repassar o que tenho aprendido e aprender mais com quem visita e comenta. Inclusive quando digo que aceito colaboração eu quero dizer que se quiser escrever um post e me mandar eu coloco no blog com seu nome. Mas vamos ao seu comentário.
As minhas definições foram simples mesmo, a idéia era mostrar o panorama do assunto pra quem não sabe nada sobre ele. Pra quem já trabalha com MVC, esse post pouco vai servir, mas pra quem ainda ta apanhando, acredito que vá ajudar a começar a entender e pesquisar mais a fundo.
Fiquei meio confuso quando você disse que MVC não são camadas e sim uma maneira das camadas conversarem. Apesar de saber que você conhece mais de MVC do que eu, vou me permitir discordar de você até que você me convença do contrário. MVC é uma metodologia que prega a divisão do software em camadas sim, indo na contramão do desenvolvimento de software monolÃticos. Pra ficar mais bonito (rs), MVC é um padrão arquitetura que divÃde o software em modelo; que são os dados e a lógica da aplicação (como você sabidamente me corrigiu); em visão, que é a interface com o usuário e em controlador, que é o responsável pelo fluxo da aplicação.
Sobre conversa entre camadas, o framework MVC deve possibilitar que eu possa no controller ou na view fazer chamadas a métodos privados do meu model, certo?
Vamos imaginar um exemplo pra ficar mais claro. Suponha que eu tenha uma classe (modelo)Tarefa, dentro dessa classe tarefa eu tenho o método criar. Eu também tenho um controlador chamado Agenda e um método chamado criar_tarefa. Se quando eu chamar o meu controlador via http://meu_site/agenda/criar_tarefa o meu controlador não tiver acesso ao método criar do meu modelo Tarefa, então nada vai funcionar e o MVC não vai me servir de nada, certo? Por isso que eu disse que o framework deve permitir a conversa entre as camadas.
Muito bom o comentário do item três, acredito que muita gente cometa o erro de colocar a lógica do modelo no controlador e não no modelo, criando como você disse, modelos burros que não teriam utilidade se eu precisasse reutilizá-los em outra aplicação.
Cara, valeu pelo comentário, espero que você continue a discussão pra gente chegar a um consenso sobre MVC.
Abração.
3-01-2007 Ã s 10:42
Pessoal, dei uma atualizada no texto deste post com base nas correções do Danilo, dêem uma conferida.
Abraços.
4-01-2007 Ã s 14:37
Olá Alexandre, fico feliz em contribuir com o site.
Vamos lá:
“Fiquei meio confuso quando você disse que MVC não são camadas e sim uma maneira das camadas conversarem.”
Vamos melhorar essas definições. A Arquitetura de Camadas nada mais é do que uma proposta para dividirmos logicamente (ou até fisicamente) os componentes de um software. Ou seja, deve-se agrupar os componentes que tem responsabilidades em comum a fim de promover um maior nÃvel de coesão da aplicação. Não confundir o termo componentes aqui com objetos visuais, mas sim tudo que diz respeito a classes, funcionalidades, etc. Todas as “ilidades” desse tipo de implementação todos já sabemos: Flexibilidade, manutenibilidade, reusabilidade entre outras. No entando a arquitetura de camadas não define COMO essas camadas se interligam ou interagem e isso leva, muitas vezes, a sistemas altamente acoplados onde as camadas se conversam como bem entendem utilizando componentes ou sub-componentes umas das outras. Geralmente o tipo de gráfico usado para definir camadas, principalmente 3-camadas (3-tier) é linear e a camada de Negócio fica entre a Apresentação e Dados. (não esqueça essa arquitetura pode ser 1-tier, 2-tier, 3-tier ou n-tier).
O problema começa quando essa integração entre camadas começam criar um emaranhado de fluxos que acabam prejudicando o software de maneira geral. E isso tende a piorar quando existe uma interface gráfica no meio da história, que hoje é comum mas que quando foi criado o MVC, meados de 70, não se falava muito em GUI (Graphical User Interface). Ainda tem muito assunto pra tratar aqui, mas vamos continuar.
Para reduzir os problemas de alto acoplamento entre as camadas foram (e estão sendo) criados alguns Design Patterns. Na verdade não foram criados e sim “descobertos”, alguém desenvolvia um bom padrão ali outro aqui e foi-se documentando tais sucessos. O MVC nada mais é do que um conjunto de Design Patterns integrados, trabalhando em conjunto para reduzir o acoplamento e melhorar o desenvolvimento e integração das camadas de software. Entre esses padrões se enquadram o Observer e o Strategy (vide Head First – Design Patterns). Esse modelo que atua em cima das Camadas (não necessariamente 3-tier) propõe um gráfico em forma de triângulo (vide http://java.sun.com/blueprints/patterns/images/mvc-structure-generic.gif ) onde existe uma “norma” de integração onde o Controller faz solicitações ao Model, sendo que essas solicitações provém ou não de uma interação com o usuário e o Model por sua vez informa sua mudança de estado (se houver) ao View, que no caso observa por mudanças no Model. Só isso. Existem pequenas diferenças no modelo MVC de acordo com a necessidade, mas o mais comum é a View e o Controller ficarem na camada de Apresentação e o Model na de Negócios. Esse modelo é o mesmo do MVC do Smalltalk e não é o mesmo usado hoje nas aplicações Web. Em algum lugar vc citou “E eu achando que MVC era pra web apenas”, na realidade é totalmente o oposto, pois na década de 70 desenvolvimento web sequer era discutido. O modelo atual de MVC implementado na web é o que chamam de Model-2 (na verdade isso é meio contestável, já li em outros lugares que Model-2 é outra coisa), pois na web não tem como implementar o pattern Observer e isso tem que ser feito de outra forma, no caso usando um Front Controller.
Abaixo seguem algumas referências:
http://java.sun.com/blueprints/patterns/MVC-detailed.html
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html
http://en.wikipedia.org/wiki/Three-tier_(computing)
“o framework MVC deve possibilitar que eu possa no controller ou na view fazer chamadas a métodos privados do meu model, certo?”
Mas o objetivo dos métodos privados e não serem visÃveis por nenhuma outra classe.
“(modelo)Tarefa, dentro dessa classe tarefa eu tenho o método criar.”
Naõ entendi bem. A classe tem um método para se criar uma instância de si mesma?
“Por isso que eu disse que o framework deve permitir a conversa entre as camadas.”
Claro que permite, em momento nenhum eu disse o contrário. Porém ele aconselha que seja seguidas algumas regras para isso.
abraço.
Danilo G. Magrini
MarÃlia / SP
26-01-2007 Ã s 21:40
[...] [Em pt_br] 4) Ruby on Rails in Brazil 5) Ruby on Br – Comunidade bem bacana 6) Wikipedia falando sobre RoR 7) Outra introdução sobre RoR em português. 8) Outro tutorial prático sobre Rails 9) Rails para diversão e lucro – conteúdo muito bom! 10) Blog do Eustáquio, figurinha carimbada e autor do livro Ruby: Conhecendo a linguagem 11) Balance On Rails, de outro cara carimbado, Fabio Akita, autor do Repensando a Web com Rails (aliás, peguem o capítulo demo). 12) juca on rails – o cara fez um mini curso de Rails por IRC. No blogue tem todos os logs das aulas. Além disso, tem um ótimo post sobre livros da linguagem. 13) Tecnologias Web – blog falando de Rails. Tem um post falando de que diabos é esse tal de MVC. [...]
20-04-2007 Ã s 22:36
Muito bom o seu post….
22-04-2007 Ã s 11:26
[...] Referência: http://alexmrg.wordpress.com/2006/12/28/what-the-fuck-is-mvc/ [...]
1-05-2007 Ã s 11:52
[...] Quanto aos padrões de desenvolvimento, me refiro por exemplo ao MVC, que é um design pattern para abstração de dados e provavelmente é o conceito mais importante do Cake. Não vou entrar em detalhes, mas tem uma explicação legal aqui. [...]
5-07-2007 Ã s 11:15
Muito bom! Valeu!
15-07-2007 Ã s 12:34
Danilo, ótima abordagem. Estou iniciando o desenvolvimento de um framework MVCpara Web e tenho visto que na prática nem o Modelo 2 tem a aderência completa para todas as linguagens ai disponÃveis.. Daà a necessidade de utilizar substituição de padrões para recompor a arquitetura. Se puder Danilo, passa seu e-mail para que eu possa tirar umas idéias com você, sobre o meu projeto.
2-08-2007 Ã s 08:57
email: danilo.magrini@gmail.com
8-10-2007 Ã s 12:25
[...] What The Fuck Is MVC? [...]