Olá,
Alguém sabe me explicar a diferença entre o modelo MVC e o de 3 camadas (camada de apresentação, de negócio e de persistência)? Onde fica a camada de persistência no modelo MVC?
No Model
Olá
Uma aplicação distribuida com arquitetura de n camadas exige uma separação lógica e física entre os componentes que podem então se distribuir por múltiplos servidores. A arquitetura MVC separa claramente a funcionalidade em distintos conjuntos de componentes e por isto é naturalmente usada em sistemas distribuidos com n camadas.
O modelo MVC tem sido usado para explicar os frameworks que usam front controller para separar a apresentação das regras de negócios. A divisão do sistema em 3 ou mais camadas visa facilitar a eventual troca de componentes. Como explico abaixo, se você quiser ser bem rigoroso devia falar em arquitetura M*VC pois a camada modelo comumente se subdivide em outras camadas. Tentarei explicar melhor:
Falar em sistema de 3 camadas ficou meio esquisito agora onde é comum ver sistemas assim:[list]- camada de apresentação -swing, swt, xul, browser (V)
- camada de controle - servlets, JSPs ©
- trocentas camadas com lógica de negócio - JDBC, EJBs, JMS, JTA, JAXP, JAF, JCA, etc. (M*)[/list] As trocentas camadas podem conter vários bancos de dados mais muitas outras aplicações rodando em diversos servidores mais aplicações em mainframes e tudo o mais que pode estar por trás dos panos que o usuário da telinha no micro jamais imagina que esteja acontecendo. As camadas de persistência podem estar no meio destas trocentas camadas que incluem também toda a infra-estrutura de serviços. Estou considerando camada como aplicações que trocam informações entre si seja via troca de mensagens ou arquivos de configurações.
Como vê é tudo questão de nomenclatura, no fundo estamos falando de aplicações distribuídas. Para explicar frameworks basta falar em MVC. Para explicar o que acontece quando o lojista passa seu cartão de crédito na maquineta pode ser que seja preciso falar de todas as outras camadas com as informações viajando milhares de quilometros.
[]s
Luca
Olá pessoal.
Segundo um artigo de Fernando Lozano da Java Magazine, o “M” do MVC incorpora as camadas de NEGÓCIO e de PERSISTÊNCIA. O “V” e o “C” incorporam a APRESENTAÇÃO.
Luca as JSPs não seriam para a camada (V), para não misturar lógica com apresentação?
Abraço,
Orlando Cesar Martins
Olá
Coloquei JSPs na camada de controle porque na verdade há um servlet gerado a partir do JSP. É óbvio que jamais passou pela minha cabeça que as tags html dos JSPs pudessem ser consideradas como Controle (apesar de construídas dentro do controle).
Se o grande Fernando Lozano falou isto ele não deixa de estar certo mas é claro que fez uma simplificação. Nem sempre os sistemas são tao simples assim. Nem sempre é bom os sistemas misturarem apresentação com controle e nem sempre o modelo é composto apenas de camadas de negócio e persistência. Por exemplo: um serviço de e-mails é negócio ou persistência?
[]s
Luca
Luca, quando falei da JSP na camada de controle é porque a JSP pode muito bém exercer também o papel de controle que seria um erro certo?
[quote]
Por exemplo: um serviço de e-mails é negócio ou persistência? [/quote]
Acredito ser negócio.
Orlando.
Olá
Isto já está virando um chat. Se serviço de e-mail é negócio você acharia que o serviço de troca de mensagens assíncronas com outros sistemas através de JMS também fazem parte do negócio? E se estes e-mails e mensagens não beneficiarem em nada o usuário do sistema e servirem apenas para administrar o sistema, você continuaria achando que pode englobar a infra-estrutura de serviços na camada de negócio?
E os serviços de logs, autenticação, cache, etc. Se todos os sistemas fossem simples assim só com persistência e regras de negócio não teria sentido pesquisar novas técnicas como AOP por exemplo para separar serviços da lógica. É claro que o Lozano precisava ser didático e por isto simplificou tudo.
[]s
Luca
[quote]Falar em sistema de 3 camadas ficou meio esquisito agora onde é comum ver sistemas assim:
- camada de apresentação -swing, swt, xul, browser (V)
- camada de controle - servlets, JSPs ©
- trocentas camadas com lógica de negócio - JDBC, EJBs, JMS, JTA, JAXP, JAF, JCA, etc. (M*)[/quote]
Luca, mas a camada de controle não é onde deveria estar as regras de negócio?
Vou tentar reestruturar detalhar mais a minha dúvida. Pelo que eu estava entendendo o MVC e o 3-Camadas são padrões diferentes. O MVC é mais voltado para desenvolvimento de GUI, enquanto que o modelo 3-camadas é uma abstração de sistema que inclui o conceito da camada de persistência.
View--Controller +---------------+
\ / | Apresentação |
\ / +---------------+
Model | Megócio |
+---------------+
| Persistência |
+---------------+
MVC 3-Camadas
Pelo que eu imaginava a junção dos dois modelos ficaria da seguinte forma:
+---------------+
| V ------- C |
| \ / |
+---------------+
| Megócio |
+---------------+
| Persistência |
+---------------+
onde o modelo ficaria na camada de persistência. Aí cada camada seria isolada por um componente Fachada. Esse pensamento está correto?
Olá
View--Controller +---------------+
/ | Apresentação |
/ +---------------+
Model | Megócio |
+---------------+
| Persistência |
+---------------+
MVC 3-CamadasA figura acima está bonita e você chama logo a atenção para a confusão entre os modelos. O livro do Husted de Struts (Struts in action) desfaz a confusão modificando a tradicional figura triangular do MVC para algo assim:
+----------------+ +--------------+ +---------------+
| V-Camada de | | C-Camada | | M-Lógica da | Banco
| apresentação |-------| de controle |-------| apresentação |---de
+----------------+ +--------------+ +---------------+ dados
Não, só se o sistema for muito simples e de vida curta que não justifique separação de camadas. Exemplo: um site feito apenas para cadastrar inscrições para um único evento. Terminado o evento o site morre e neste caso seria aceitável este modelo errado.
O MVC surgiu no Smaltalk muito antes de se falar em web. Depois foi aproveitado na documentação do Swing que é desenvolvimento GUI e mais tarde foi modificado um tiquinho para virar MVC2 na documentação dos frameworks de front controller. Ainda serve para ajudar o entendimento mas não exatamente para modelar rigidamente uma aplicação.
A denominação modelo de 3 camadas com a 3a camada sendo de persistência é herança dos antigos sistemas cliente servidor chamados de 2 camadas onde uma separação a mais os fazia virar 3 camadas.
Hoje falamos de sistemas distribuídos de n camadas. Como todo o linguajar é mais usado em documentação de sistema há sempre uma certa confusão de nomenclatura. Isto é absolutamente normal. Mas onde não pode haver confusão é na definição da arquitetura. Chame como quiser mas não misture coisas que podem fazer você mesmo de vítima no futuro. Misturar TUDO em um modelo único só para ficar parecido com a figura tradicional do MVC ou com o linguajar antigo de 3 camadas pode ser completamente errado.
Deve ter havido um errinho de revisão. É exatamente o contrário: a persistência é apenas uma das muitas camadas que podem compor o modelo.
[]s
Luca
Olá Luca,
Mas o MVC não utiliza um encapsulamento para a camada de persistencia? E se eu mudar meu sistema de um banco de dados relacional para um bd XML? Isso não trará problemas?
A aplicação que estou desenvolvendo é em swing, mas futuramente penso em implementar um outro módulo em web service. Qual a arquitetura que devo utilizar?
[]'s
Davi
Olá
Sugiro estudar bem esta questão de arquitetura de sistemas. Alguns conceitos ainda precisam amadurecer. Por ora antecipo que MVC não encapsula nada de persistência e que se pode usar webservices com swing do mesmo modo que com outras camadas de apresentação.
[]s
Luca
Para quem quer entender bem a história do conceito, o Fowler disponibilizou um capítulo da próxima edição do PoEAA aqui.
Eu comentei brevemente sobre o assunto aqui. Basicamente, o contexto original do MVC é muito diferente do que se fala atualmente. Talvez seja mais produtivo parar de falar em MVC e criar uma nova nomenclatura para as arquiteturas comuns nos sitemas web.
Olá pessoal.
Achei muito legal o assunto discutido.
Já faz algum tempo que estou vendo na net a confusão que muitos fazem sobre MVC e 3-camadas.
Seria legal se alguém pudesse disponibilisar um material de fácil entendimento sobre as diferenças entre MVC e 3-camadas.
Acho que está na hora de iniciarmos uma corrente para eliminar estas confusões.
Tem muita gente por aí que quer bancar o arquiteto, mistura tudo, e solta umas pérolas terríveis. O pior é que tem gente querendo aprender e acaba aprendendo errado!
Por favor! Não estou me referindo a ninguém deste fórum em especial.
Como já disse anteriormente, acho muito legal e de grande utilidade que que se discuta o assunto.
Bom! Não contribuí muito para a discussão mas quero chamar a ATENÇÃO para os ERROS CONCEITUAIS graves que venho observando na net sobre este assunto. Acho que com a contribuição de todos podemos reverter este quadro.
VAMOS LÁ PESSOAL!!! VAMOS DEBATER O ASSUNTO E TIRAR DÚVIDAS!!!
O modelo MVC não necessariamente possui um serviço de persistência. Um exemplo disso é o swing.
Na verdade, esse modelo só especifica a interação entre as classes. E ele também é um modelo de 3 camadas, embora não seja o 3-tier citado. As camadas são a model, a view e a controller.
A confusão acontece porque tentamos adequar diversas arquiteturas nesse modelo. Se eu tiver um serviço de persistência, onde ela entraria nesse modelo? E se tivessemos que fazer distribuição? Seria controle ou model?
Tudo depende da abstração que estivermos criando. Algumas arquiteturas, como struts, já possuem esses conceitos definidos para o tipo de problema que eles procuram resolver.
Os modelos 3-tier e o MVC são diferentes porque definem coisas diferentes. O MVC atribui responsabilidades de maneira mais genérica, podendo ser adotado num número muito grande de situações, inclusive o modelo 3-tier citado. Ele está preocupado em como os componentes interagem, não necessariamente no que eles fazem.
O modelo 3-tier é um pouco mais específico (embora seja extremamente recorrente) e procura agrupar os objetos em divisões mais concretas: persistência, negócio, apresentação. A interação não é um dos focos principais - exceto é claro pela manutenção das camadas. O foco fica mais restrito na parte organizacional e no agrupamento dessas classes, além é claro, da redução da dependência - consequência de qualquer modelo de camadas.
[quote=AllMighty]Para quem quer entender bem a história do conceito, o Fowler disponibilizou um capítulo da próxima edição do PoEAA aqui.
[/quote]
Cara estou estudando o livro PoEAA e fiquei bem triste com a abordagem que ele deu sobre mvc!
Mas creio que este novo livro dele “Development of Further Patterns of Enterprise Application Architecture” seja uma nova edição do PoEAA, pois estou achando que esse livro tem um conteúdo bem diferente do PoEAA para ser uma nova edição!
O que vc acha?