Gostaria de tirar uma dúvida com o pessoal que trabalha mais tempo com MVC, criei um diagrama para demonstrar meu conhecimento sobre este tema:
Lendo em vários artigos observei que o MVC trabalhado para programas desktop e para web é um pouco diferente, um exemplo seria a classe controle que não teria muita utilidade em programas desktop, seria mesmo para controle das passagens para a persistência, seria isso mesmo?
Sendo uma arquitetura de desenvolvimento pude reparar que em vários artigos pessoas tratam MVC de formas diferentes, porque tanta divergência?
Na verdade, é um pouco diferente disso. E não acho q tem divergências nesse padrão.
O que vc apresentou é uma modelagem em 3 camadas. Não o MVC.
O MVC mesmo, trata-se de uma camada para o Modelo, onde ficam as entidades, uma camada para a Visão, que é a grande vantagem de desacoplamento do código e facilitação para o desenvolvimento em equipe. É nesta camada q fica toda a parte de visualização do usuário. E por fim, a camada de controle que administra o meio de campo entre as duas outras camadas.
Essa idéia pode ser aplicada tanto em aplicações desktop quanto web.
Maas … !!
Obviamente a aplicação possui muitas outras camadas, isso depende muito do arquiteto. Mas para exemplificar outra camada, o Business seria uma boa pedida em uma aplicação méia ou grande.
A parte de conexão e persistência com o banco de dados não entra em nenhuma camada, ou, como algumas pessoas dizem, no máximo entra na camada de Modelo.
Se for usar o jboss seam então, vai quebrar em mais camadas a parte do controle.
Enfim, na minha opinião, este padrão de desenvolvimento é tão forte e elegante, que até a microsoft criou o MVC para .net !
Pra ser mais exato, mais do que as entidades o modelo é que define a aplicação.
Ou seja, é nele onde está definido o comportamento, a alma da aplicação, com as regras de negócio e interfaces de acesso a esses mecanismos.
Ele por si só deve funcionar independente de view e controler.
edit: completando, o acesso a dados, persistência e tudo mais, faz parte do modelo, repetindo: FAZ PARTE, mas não o define como um todo.
Não necessariamente.
Uma view para um http e outra para wap deveria partir de um mesmo controller.
O Struts previa isto, mas teria q ter dois templates. No caso do jsf, também é previsto, mas apenas um template consegue renderizar para os dois tipos.
Pensemos no seguinte:
O Controler é feito para interligar o Model com a View. Ok.
O Model não muda.
A View muda, sempre.
Logo, se o controler é especializado em ambos os pontos, a qualquer alteração deles o controler deve se adaptar.
Por isso diz-se que o controler é íntimo a view, se ela muda… ele muda.
Se o controler não muda e vc faz adaptações na view… talvez ele não seja um controler, mas façades do model (confusão muito recorrente).
Eu intendo o q vc quer dizer. E eu concordo, realmente é isso aí. Se vc quer colocar mais alguma coisa na sua view, vai ter q mudar o controller.
Mas o q vc não quer entender, é que eu posso ter um mesmo controller para duas views. Uma view para um celular e outra para o computador, as duas fazem a mesma coisa. Ter dois controllers (ALIÁS, controller não tem nada a ver com isso, controller é uma camada, quem faz isso é uma action, ou um mb) com o mesmo código para duas view diferentes seria desperdício de código.
edit: Pq o model não muda? Sua aplicação nunca cresce?
Discordo.
Se você possui uma aplicação web você tem um controler que conhece HttpSession, por exemplo. O que já não é verdade pra mesma aplicação só que swing. Não convém esse controler ser reaproveitado. Ou vai me dizer que faz sentido um controler pra um aplicativo swing conhecer HttpSession?
Como eu disse, ele é íntimo da view.
A Action e o MD são, de certo modo, controlers. Você os reaproveitaria num aplicativo swing?
Sendo assim ainda não entendi o que você define como controler, mas definitivamente ele não o é.
[quote=aluisiodsv]
edit: Pq o model não muda? Sua aplicação nunca cresce?[/quote]
Claro que cresce, mas o que disse é que não faz sentido que o model mude por conta de modifcações na view.
Se isso for necessário isso é um indício forte de que não há separação nítida de responsabilidades.
Sinceramente acho q estamos discutindo a mesma opinião.
Concordo no caso da aplicação swing. Tbm concordo com a intimidade do controller com a view.
Apenas no caso específico da aplicação gerar para html e para wap, existe uma possibilidade de tudo continuar como está no JSF. Apenas mudar a renderização.
