Olá, pessoal!
Estou precisando da ajuda de vocês!
Quando estudei MVC e em várias discussões no GUJ, sempre li que o MVC é constituído por três camadas.
A View assiste a Model.
O controller assiste a View.
Mas surgiu uma afirmação para mim que considerei como errado e estava certa.
[i]Um dos princípios do padrão de arquitetura MVC é a separação da lógica da apresentação do modelo.
PORQUE
É, muitas vezes, mais prático manter a visão e o controlador unificados, inclusive, por demandas da tecnologia.[/i]
A primeira afirmação está, obviamente, correta. A segunda, também correta, não entendi.
Alguém poderia me explicar a segunda afirmação?
A primeira questão é simples.
Suponha que você tem uma empresa e o sistema de controle dos funcionários foi construído seguindo o pattern MVC.
O projeto foi desenvolvido com a camada view em swing.
Agora, como tua empresa cresceu, é preciso manter duas filiais fora do estado e, então, o programa agora terá de ser migrado para web, com JSP/Servlet (exemplo esdrúxulo).
Como as camadas estão bem definidas, basta criar a camada web (view) da coisa. Toda a parte de controle e persistência permanece inalterada.
Agora, quando você mistura as camadas, como sugerido na segunda afirmativa, precisará recompor partes de lógica que ficam perdidas na camada de apresentação. Como fará isso? Qual o custo do trabalho (e retrabalhos posteriores)?
Claro, há paradigmas e necessidades. Também já fui um ferrenho crítico do MVC, hoje vejo, como diria meu gerente de projetos, com bons olhos essa questão. Preciso mudar a lógica, mas a tela não. Preciso trocar de Hibernate para TopLink, mas mantenho a lógica. Preciso trocar de web para desktop, mas não altero mais nada.
Simples. Trabalhoso, complicado de se fazer? Quem sabe, tudo é uma questão de costume (tem gente que prefere trabalhar com grafos de listas duplamente encadeadas em C ou assembler a programar java).
É mais prático manter visão e controlador juntos. Tudo bem aí. Mas não descaracteriza o MVC fazendo isso?
É mais prático para quem tem preguiça.
Mais trabalhoso para dar manutenção.
E ao meu ver, sim, descaracteriza o MVC.
Sim, descaracteriza.
Uma camada de controle se justifica mais nos casos em que a View e o Model estão fisicamente separados, como é o caso da web. Para sistemas desktop, geralmente usar o MVC completo é adicionar muita burocracia, sem um ganho em manutenção que valha o esforço.
Vale lembrar que em sistemas desktop:
a) É impossível o usuário “navegar” para um form inválido;
b) É impossível o usuário inserir parâmetros inválidos de entrada (a view garante 100% de precisão na validação dos dados, desde que não hajam erros de programação). O usuário não pode simplesmente pressionar esc e “desabilitar javascripts” ou simplesmente passar parâmetros “no post”;
c) É fácil comunicar-se entre as camadas do sistema. É simplesmente uma chamada de evento, sem rede, sem sniffers ou intermediários no meio.
Além disso, sistemas desktop tem interface mais rica. Aumenta muito o código se o controlador estiver totalmente isolado, para um benefício um tanto questionável. É por isso que a própria Oracle sugere um modelo MVC simplificado, com Model e Controle juntos, e classes de controle apenas onde for desejável (TableModel, ListModel, etc), e adotou essa decisão no Swing: http://java.sun.com/products/jfc/tsc/articles/architecture/
Em um sistema web, não tem cabimento não fazer a separação das três camadas.