MVC ou Arquitetura em Camadas?

17out11

Não confunda MVC com Arquitetura Camadas

Você acha que MVC e Arquitetura em Camadas são a mesma coisa? Não são! Sempre discuti este assunto com diversas pessoas, desde profissionais menos experientes até macacos velhos da área. Minha constatação: há muita confusão nos conceitos. Para deixar bem claro, resolvi escrever este post.

Antes de mais nada, não espere referências a artigos acadêmicos ou livros. O que tem aqui é o meu ponto de vista baseado em muita coisa que li e vivi, então sinta-se à vontade para complementar ou discordar. O que vale aqui é a informalidade.

Vou começar pela Arquitetura em Camadas, pois ela caiu na boca do povo antes do MVC. A ideia é dividir a aplicação em 3 responsabilidades: apresentação, negócio e persistência. Fiz esta figura aí:

Arquitetura em Camadas

Imagine usuários (pessoas ou outras aplicações) acessando uma determinada aplicação por meio de ferramentas: browser, celular, caixa eletrônico, etc. Toda interação do usuário com a aplicação ocorre na camada de apresentação: telas, serviços expostos, sensores, reconhecimento de voz, etc. É responsabilidade da apresentação interceptar e traduzir os estímulos externos para a linguagem do negócio, e vice-versa.

Na camada de negócio está a inteligência da aplicação: regras e validações de negócio. Pode-se considerá-la a parte pensante que torna a aplicação única. As demais camadas são periféricas e foram criadas para servi-la. É o núcleo da aplicação! Geralmente não é recomendável enxertar aparatos tecnológicos nela.

A camada de persistência (também conhecida como camada de integração) tem a responsabilidade de armazenar as informações geradas pela camada de negócio. No sentido contrário do fluxo, serve como fonte de dados. Esta camada pode integrar com bancos de dados, arquivos em diversos formatos, serviços de outras aplicações, interpretar ou enviar sinais para sensores externos, etc.

Supondo uma aplicação web em Java, similar a qualquer outra tecnologia web, seguindo a Arquitetura em Camadas praticada no mercado, teríamos o seguinte:

Exemplo de Arquitetura em Camadas

Um arquivo HTML dinâmico (alunos.xhtml) em parceria com seu auxiliar (AlunoMB) exibirá a listagem dos alunos no browser do usuário. A classe da camada de negócio (AlunoRN), requisitada pela apresentação, invocará a classe da camada de persistência (AlunoDAO) para obter os dados. Para atender a solicitação, a camada de persistência consultará o banco de dados.

Você deve estar se perguntando: para que cargas d’água existe a classe AlunoMB? A explicação está no padrão MVC!

O MVC surgiu com a missão de separar os elementos visuais dos elementos do negócio. Você lembra daquela aplicação porcalhona desktop, web ou mobile que você fez, onde os elementos de tela acessam diretamente (ou praticamente) o banco de dados? Tá achando graça, né?! Você achava fácil dar manutenção na aplicação? Eu sei que não!

O material mais objetivo que achei para explicar MVC foi o guia de programação da Apple. Eles usam um diagrama similar a este aí:

MVC

Existe a View, composta por todos elementos visuais ou sensoriais da aplicação: campos, teclados virtuais, tabelas, textos, caixas, imagens, vídeos, a própria tela, etc. O elemento Model é formado pelas regras de negócio e persistência. A View nunca deve acessar diretamente o Model, você bem sabe a bagunça que isto causa! A função do Controller é fazer a cola entre View e Model.

Voltemos ao mesmo exemplo, desta vez pensando MVC:

Exemplo MVC

O arquivo HTML (alunos.xhtml) que representa a tela é uma View. Na tela, existem outros elementos visuais, que também são Views, e não foram representados na figura. Os eventos da tela estão associados ao Controller (AlunoMB), que invoca elementos Model (AlunoRN) para atender a requisição.

Tá vendo?! A mesma aplicação sob a ótica da Arquitetura em Camadas e MVC. Não sai faísca, ambos podem viver juntos sem problemas. Ainda diria mais: as duas abordagens se completam! Então fica a dica: cuidado para não confundir os conceitos, você encontrará muitas armadilhas pelo caminho 😦

Anúncios


27 Responses to “MVC ou Arquitetura em Camadas?”

  1. 1 William

    Perfeito!

    Eu estava discutindo com um colega de trabalho sobre isso e expliquei algo semelhante. Bom saber que não falei merda pra ele.

    Ainda escrevendo este comentário um colega pra quem eu passei esse link já discordou dizendo que era a mesma coisa (rsrs).

  2. 3 Joselito

    Um detalhe importante é que as implementações dos backing beans no Jsf trazem enraizadas essa confusão entre os dois conceitos. Os Beans do jsf tem muita coisa de MVC misturado com alguma coisa de framework component-based.
    As melhores (e únicas ) implementações verdadeiramente MVC que conheço são a do Swing (desktop) e a do Wicket, que é praticamente uma adaptação pra Web do modelo de desenvolvimento desktop.

    • 4 mariojp

      O MVC puro tem troca de mensagens entre o View e o Model. Rolou uma adaptação, principalmente por conta da WEB, que gerou o que muitos chamam de “MVC2” onde tudo passa pelo Controller.

  3. 5 Igor Cavalcanti Ramos

    Olá, primeiro gostaria de dizer que seu artigo é muito útil, mas também de dizer que penso que o “Model” do MVC, nesse caso, é apenas a camada “AlunoRN”. Bom, preciosismos à parte, parabéns. =)

  4. 7 Salazar

    Bem legal o texto e realmente é um assunto com diversas visões. Por exemplo, considerando que as entidades constituem parte do Model, não acho válida a afirmação: “A View nunca deve acessar diretamente o Model”. A Figura http://pt.wikipedia.org/wiki/Ficheiro:ModelViewControllerDiagram2.svg ilustra a ideia.

  5. Muitas pessoas – especialmente as que utilizam JSF – consideram os ManagedBeans como parte da View, talvez considerando que eles são “dependentes” do binding do JSF. Mas concordo totalmente com você. Para mim, os MBs são um caso clássico de Controller no modelo MVC, tratam os eventos de usuário e interagem com o Model (RN+DAO).

  6. Zyc pq vc não faz um artigo sobre DDD?

  7. Muito bom, ZyC! O pessoal confunde muito mesmo! Além disso, há divergências conceituais entre as pessoas.

    Como você acrescentaria o AlunoDTO no contexto deste post? O que seria ele?

    Já antecipo minha opinião de que a depender do cenário de uso, AlunoDTO acaba virando uma anomalia.

    Um abraço

    • Cara, não coloquei os Objetos de Transferência de Dados (DTO) de propósito para não polemizar. Como seu objetivo permeia transversalmente as camadas, o que é comum para alguém que tem como objetivo transportar dados, no meu ponto de vista ele não se enquadraria nesta perspectiva. Caso fosse representá-lo nesta abordagem, ele seria um retângulo atravessando todas as camadas.

      Se pensarmos em outros tipos passíveis de servirem como transferidores de dados (como textos, inteiros e vetores), assim como uma entidade de sua aplicação, elas seriam consideradas também uma variação de DTO? Talvez sim, talvez não… Depende muito, novamente, do ponto de vista.

      Normalmente as representações utilizadas no dia-a-dia consideram o DTO, mensagens, segurança e transação como elementos que transcendem estas camadas, e que são representados como citei aí sobre o DTO: um retângulo que passa por todas.

      Como você trataria este assunto?

      • 13 Fábio

        Na minha opinião o DTO não está em nenhuma camada, sendo apenas uma representação de dados, como o próprio nome sugere. Por sinal, um DTO é um padrão superestimado, sua aplicação é questionável em muitos casos.

  8. A separação entre o negócio e Persistência, além da controller estão sendo os grandes diferenciais nos dois conceitos. Mas ainda sim pode conceituar toda MVC é separado em Camada, mas nem toda aplicação em camada , Proprieamente é um MVC

  9. 15 Eduardo

    1 camada: cliente possui um “monitor”, mainframe faz tudo dentro de uma arquitetura “fechada”.
    2 camadas: cliente divide a carga de processamento pois agora possui um PC, com capacidade de renderizar componentes gráficos e recursos de usabilidade (ex. javascript), as regras de negócio e persistência ficam no servidor.
    3 camadas: o banco de dados se tornou a principal ponto de integração, então precisa ser gerenciado separadamente por um DBA, então o BD virou uma camada.
    N camadas: levando em conta EAI (Enterprise Application Integration)
    MVC: design pattern para não misturar lógica de apresentação com lógica de negócio. O DTO/DAO foi algo que ganhou força no mundo EJB para criar a transparência de acessar um objeto local/remoto.

  10. 16 Jader S. Santos

    A questão é que existem o MVC e o MVC2. O primeiro também era usado em aplicações cliente-servidor. Autores importantes falam de MVC como uma arquitetura em três camadas, e isso acaba deixando o assunto bastante confuso.

    No link abaixo pode-se ter uma ideia melhor do que estou falando:

    http://www.webartigos.com/artigos/abordando-a-arquitetura-mvc-e-design-patterns-observer-composite-strategy/20878/

    Eu achei muito legal o post, e concordo plenamente com a visão de que o MVC não é a mesma coisa que aplicação em três camadas, e seria até mais coerente dizer que é utilizado em aplicações N-camadas. Em jsf ou struts o controller está muito ligado à view, e se pensarmos que as camadas devem ser completamente independentes e substituíveis, se pegarmos uma aplicação desenvolvida com struts e jogarmos fora a camada de apresentação, os controllers vão junto.

  11. 17 Augusto Neto

    Muito Bom! Acabou de tirar uma dúvida, tbm achava que arquitetura em camadas e padrão MVC de completavam. Resolvi dá uma pesquisada e de cara cai no teu blog.

  12. 18 Victor Lippi

    Bem legal o post. Demostra pontos de vista interessante, só que me faz pensar sobre o ponto central de tudo. Ex: digamos que desenvolvi uma aplicação com JSF pra rodar em browser e em seguida quero fazer uma nova camada de apresentação para poder abrir a app no celular e para isso mudo alguns dados a serem apresentados (teria que popular outros VO’s). Essa mudança na camada de apresentação faz o resto ir pro saco?

    • Depende…

      Caso 1: Sua nova necessidade de apresentação (mobilidade) identificou melhorias no negócio. Neste caso, uma atualização no negócio é necessária e você pode decidir como fazê-la: causando muito ou pouco impacto para o que já existe. Só você poderá avaliar.

      Caso 2: Sua nova necessidade de apresentação (mobilidade) precisa apresentar novos dados que não impactam no negócio. Neste caso, os DTO do seu negócio não precisam ser necessariamente os mesmos da sua camada de apresentação. A conversão de um DTO (negócio) em outro (mobilidade) é de responsabilidade da camada de apresentação (mobilidade).

      O ideal é manter a arquitetura o mais simples possível para atender sua necessidade. Quanto mais flexibilidade na arquitetura, mais trabalho para mantê-la. O segredo está em conseguir equilibrar esta balança.

      • 20 Victor Lippi

        Legal. No caso 1 compreendo, mas me refiro ao caso 2 mesmo. No caso 2 você quer dizer que se existem 2 apresentações, o DTO(negócio) é populado com todos os dados (tudo que as 2 apresentações precisam) e cada apresentação pega apenas o que precisa exibir, seria isso?

  13. 21 Tiago Santana Machado

    Perfeito! Clariou muitas duvidas minha.

    Obrigado amigo

  14. 22 Jeferaleite

    Parabéns pelo artigo! A linguagem informal facilita muito o aprendizado, excelente iniciativa…
    Vejamos, JSF assim como Struts tem uma proposta de MVC, voltando ao passado, em uma JSP com Scriptllets era possível usar HTML, JAVA, ACESSO a DADOS, “opa” Uma Mono-Camada. Agora imagine que com o JSF, a aparência fica no XHTML isso seria a viu, o MBean processa a navegação na fronteira do sistema, olha ai “Controlador” Front Controller, e as entidades representam o Modelo. A grande pergunta: E o acesso a dados, pense que no Mbean um framework com o entitymanager JPA pode fazer este papel. Logo percebemos que um MVC pode ser uma estrutura simples para atender a uma questão muito mais Simples. Uma arquitetura em camadas provê uma separação mais conceitual, uma camada de apresentação pode ser o próprio Framework JSF, uma camada de negócio fica sendo o coração do sistema executando cálculos consumindo recursos advindo de uma camada de acesso a dados controlando transações e provendo alta granularidade a outras camadas que consomem negócios. Por fim, uma camada de acesso a dados, onde há uma separação lógica do acesso a dados, é la que você vai encontrar consultas, inserções, alterações etc…etc… tudo referente a persistência, claro que esse papo da assunto para um livro, mas, fica ai minha opnião!!!

  15. 23 guilherme

    continuo não vendo a diferença

  16. Na era Web o pessoal faz muita confusão, mas vale lembrar que o MVC veio lá do smalltalk para aplicações desktop, muito antes de existir HTTP com request/response, que complica entender. V -> código responsável por desenhar aquilo que o usuário interage. M -> código do modelo conceitual da aplicação, deve ser agnóstico à tecnologia de visão, ou seja, tem que ser possível usar o MESMO MODEL para diferentes visões, tais como: console, desktop, web, app mobile, alavancas e potenciêmtros num painel de alumínio escovado, webservice, etc. Outra coisa, não pressupõe persistência… Se existe, faz parte, senão, não precisa. Muita gente acha que Model são só as entidades mapeadas, o que é um simplismo muito grande. C -> Faz a cola entre os eventos da visão e o contrato do modelo, assim como escuta mudanças no modelo para solicitar que a visão seja redesenhada (não natural de ser feito na web tradicional), dessa forma, logicamente é dependente da tecnologia de visão. Dito isso, o controller por natureza do JSF é o FacesServlet, mas você precisa dirigir esse Servlet fazendo uma cola entre XHTML e MB. Por isso eu diria que o MB é tudo menos modelo. Opinião pessoal: é controller. A questão é que alguns MB’s ficam tão suaves, são praticamente JavaBeans limpinhos, com getters e setters e um ou outro método que acabamos chamando num evento de tela e daí podem servir a várias tecnologias de visão, parecendo muito com um Model…. Mas a prática mostra que telas complexas requerem MB’s cheios de molecagens e muito-muito amarrados com o XHTML. Alguns chegam a conter ID’s de componentes em seu código. Esses MB’s inclusive são difíceis de serem testados via testes unitários, e o melhor teste para eles acaba sendo um teste caixa preta automatizado com um Sellenium por exemplo. Daí eu tiro uma boa conclusão utópica, mas que dá um norte: um MB puro deveria se resumir a manter um estado mínimo entre cliques (em casos extremos) e oferecer métodos de resposta a eventos do XHTML (ex: onClickBtSalvar, onChangeSelectUF, etc.), sempre delegando a qualquer decisão para uma classe de Modelo devidamente amparada por testes unitários, etc… As vezes essa classe é direto um BC, as vezes não. Mas é importante ser um Model, agnóstico à tecnologia de visão. Mas essa discussão é grande e cá pra nós, muito filosófica! Kkkkkkkk… Já é tão difícil convencer os cabras da equipe a não escrever uma regra de negócio inteira dentro de um método isRenderedBtExcluir() do MB ao invés de delegar para um BC…. Agora com essa popularidade de arquiteturas HTML + REST acho que vamos portar essa problemática lá pras aplicações web do front, onde as coisas estão meio afobadas… Nos vemos por lá!


  1. 1 Objective-C e RESTful Web Services « Cleverson Sacramento
  2. 2 Objective-C e RESTful Web Services « Demoiselle Laboratory

E aí, o que você achou? Comenta aí...

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s