Entre as respostas digo que MVC não são camadas, que Controller é intimamente ligada à View, que Model deve estar desacoplada ao Model e outros conceitos mais comuns. Lógico que não dá pra cobrir tudo, por isso pensei: e vocês? Já tiveram uma sensação sobre MVC que não entrava na cabeça? Ou então: já ouviram alguém falando sobre MVC que achou errado?
Pra mim está aqui a raiz do problema. O cara le que struts/jsf/sei-la-o-que-mais é um framework mvc, aí ele vai dar uma estudada em o que é mvc. Evidentemente essa “estudada” é dar uma olhada meio por cima em alguns blogs e artigos.
Esses blogs e artigos definem o que é mvc para desktop. O programador se confunde todo e no meio do caos que ele está aparece a frase, divida sua aplicacao em apresentacao, negocio e persistencia. E pronto, ta feita a confusao.
O conhecimento de um programador é como o bom senso, ninguem acha que precisa ter mais do que tem.
A primeira vez que tive contato com o MVC foi frustrante. Principalmente porque o cara que me “ensinou”, ensinou tudo errado. Na época eu simplesmente não via sentido no MVC e achava que ele era uma complicação bizarra e sem sentido. Mas hoje, sei que o que era bizarro e sem sentido era o que o cara achava (e provavelmente ainda acha) que é MVC.
Também concordo com o YvGa, mas acho que o problema é bem maior. Há muita gente por aí espalhando e postando coisas que dizem ser MVC mas são apenas uma versão distorcida e degenerada dele, tal como ocorreu com o cara que me “ensinou” isso. Esse tipo de coisa apenas causa confusão e desinformação e cria o efeito que vejo atualmente de “cada um tem uma definição diferente do que é o MVC”.
Particularmente, uma coisa que odeio são os decoradores de framework que “aprendem a mexer” com struts, spring, JSF ou RoR, e que adoram abusar da sigla MVC como buzzword e a utilizá-la esbanjadoradamente mais por questão de marketing do que pelo conceito, mesmo sem saber direito o que a sigla significa. Dizem religiosamente que o seu framework preferido é a única forma correta existente de se usar o padrão MVC, e consideram uma heresia grave quem ousar discordar deles.
Eu particularmente, nunca achei uma implementação que julgasse ser plenamente correta e limpa do padrão MVC, incluindo as que eu mesmo fiz. Mas uma coisa que sei é que embora nunca tenha visto uma implementação plenamente correta e limpa, sei que existem diversas formas possíveis diferentes plenamente corretas e limpas. Incluindo algumas que não são nem o chamado MVC web e nem o chamado MVC desktop (alguém já parou para pensar que o MVC web do jeito que costuma ser definido é relativamente limitado em relação ao ajax? Eu já!)
Acho que você está meio estagnado no tempo. Definir um MVC web como algo que exclusivamente recebe eventos de submissão é nunca ter ouvido falar de web 2.0.
Exato! E é aí que o tão chamado “modelo web MVC” começa a quebrar. Logicamente, para dar um jeito nisso a saída preferida do pessoal costuma ser a famosa gambiarra. Mas, curiosamente muitos se preocupam em definir o MVC, mas poucos se preocupam em redefinir o MVC.
Acho que um primeiro passo para o esclarecimento do mvc seria parar de chamar o modelo web de mvc. Ele nao tem nada a ver com a descricao originao do padrao, com seus observers e subjects e etc…
Web 2.0 é uma característica de aplicações web que tem caráter mais social. Pouco tem a ver com a tecnologia utilizada.
Talvez você esteja se referindo a AJAX. E nesse caso, pra uma aplicação extremamente ajaxificada, a arquitetura não é muito diferente de um desktop que “puxa coisas” do servidor: você tem uma aplicação Javascript que roda no cliente, e outra aplicação Java/ASP/PHP/Rails que roda no servidor. São duas aplicações onde cada uma tem seu MVC porque, como havia dito: não existe MVC distribuído. E no caso da aplicação servidor, ele exclusivamente recebe eventos de submissão, pois não dá pra saber se a origem é de um componente Ajax ou não.
[quote=fantomas]mochuara, você pode falar um pouco mais sobre esta sua afirmação? Achei interessante.
flws[/quote]
Essas eram as tecnologias que estavam na crista da onda na era da Web 2.0 mas eu percebo que há muito descontentamento com elas agora. Minha impressão é que apesar de serem coisas diferentes, elas compartilham algumas características sobre como frameworks e middlewares, enfim, plataformas são empurrados para o consumo geral como se fossem produtos ao invés de serviços.
[quote=thimor]
Onde você coloca o negocio nesse caso? Teriam Business Objects? Ou o negocio e a persistencias sao o model? O model não seria apenas POJOS?[/quote]
Nao, model nao sao apenas pojos, model eh tudo o que nao eh view. Services, facades, factories, repositorios, arquivos de configuracao, datasources, database, tudo é model.
Controller eh o que a view usa para modificar o modelo. No caso da web eles sao responsaveis tambem por encontrar a view a mostrada ao usuario, em desktop nem isso.
MVC NAO é apresentacao/dominio/persistencia. Uma coisa é uma coisa, outra coisa é outra coisa. MVC é apenas uma das formas de se separar apresentacao de dominio.
Na minha opinião, pra implementar MVC (como foi concebido inicialmente) na Web o componente View deveria observar o model. Que hoje em dia dá até pra fazer usando Ajax reverso, mas quase ninguem faz porque poucas aplicações tem essa necessidade. Geralmente se chama de MVC diversas implementações que nada tem a ver com isso. Por isso surgiram os tails MVC2 ou Model 2 ou XPTO da vida. Mas isso é só a minha opinião, não sou o dono da verdade.
É a mesma coisa que está acontecendo com Scrum hoje, gerentes que tiram o produto da caixinha, começam a usar, e acham ruim pq não tá dando certo. Ningúem lê o fucking manual pra saber como usar, ou mesmo pra saber pra quê serve ou se precisam de verdade, acabam levando supositório achando que tá comprando aspirina.
[size=9]PS: Não estou falando que a metodologia é um produto, estou me referindo ao auê que fazem sem saber o que é na verdade.[/size]
Quando ouvi falar de MVC pela primeira vez, em uma disciplina de estrutura de dados, achei aquela idéia muito legal.
A princípio não entendi precisamente como funciona esse bixo e achava realmente isso que o colega diz não ser:
Por um tempo permaneci na ignorância achando que era isso, talvez por não ter, na época, com quem conversar sobre isso (não participava do GUJ, programava em C++) e ficava feliz fazendo meus God Objects dizendo “to usando MVC”.
Felizmente depois de um tempo refleti bastante e fui contestando aquilo que eu jugava saber sobre MVC.
Após ler bastante e principalmente quando comecei a trabalhar com Java meu contato com patterns cresceu bastante e continuo contestado a utilização de cada um deles, como acredito que deva ser feito por todos (principalmente arquitetos de sistema, ouviram? hehehehe).
Hoje consigo definir um modelo MVC muito mais fiel aquilo que ele se propõe, acredito, e não aquela visão distorcida que tive, por ter aprendido errado num primeiro momento.
Certa vez estava refletindo sobre a dependência da view com a controler e cheguei a conclusão de que pra cada View uma nova Controler deve ser concebida, uma vez que, como já citado anteriormente, essas duas “camadas” estão intimamente ligadas.
Conclui então que a “camada” model é composta por todo o “core” do projeto, onde a lógica de negócios estã implementada, junto a persitência e outras cocitas e pode(deve) ser organizado em “subcamadas” definidas.
Já vi muitos projetos que dizem implementar MVC com essas responsabilidades todas misturadas, inclusive comentendo heresias que prefiro não citar por aqui, o que me levou a pensar a respeito daquele projeto: “mvc uma ova!”. Entre outros crimes hehehe de arquitetura.
Espero ter me espressado corretamente, qualquer coisa estou aberto a discuções e por favor, caso discordem eu peço que dêem sua opinião, algo que aprendi muito nos últimos anos foi a ouvir.
A propósito, alguém poderia sugerir uma denominação pra que eu usasse no lugar de “camada” ?
Isso ta me deixando desconfortável, mas não consigo encontrar expressão melhor.