18/04/2022 11:57 MVC ou Arquitetura em Camadas?

| Cleverson Sacramento

Cleverson Sacramento
MVC ou Arquitetura em Camadas? 17out11

(https://cleversonsacramento.files.wordpress.com/2011/10/mvc-camadas.png)
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í:

(https://cleversonsacramento.files.wordpress.com/2011/10/arquitetura-camadas.png)
Arquitetura em Camadas

https://cleversonsacramento.wordpress.com/2011/10/17/mvc-ou-arquitetura-em-camadas/ 1/8
18/04/2022 11:57 MVC ou Arquitetura em Camadas? | Cleverson Sacramento

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:

(https://cleversonsacramento.files.wordpress.com/2011/10/diagrama-camadas1.png)
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
(http://cleversonsacramento.com/2011/09/22/rolou-objective-c-no-linguagil-2011/). Eles usam um
diagrama similar a este aí:

https://cleversonsacramento.wordpress.com/2011/10/17/mvc-ou-arquitetura-em-camadas/ 2/8
18/04/2022 11:57 MVC ou Arquitetura em Camadas? | Cleverson Sacramento

(https://cleversonsacramento.files.wordpress.com/2011/10/mvc.png)
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:

(https://cleversonsacramento.files.wordpress.com/2011/10/diagrama-mvc3.png)
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

Filed under: Post   |   27 Comments

Tags:Arquitetura
27 Responses to “MVC ou Arquitetura em Camadas?”
Feed for this Entry
Trackback Address
1
William on 17/10/2011 said:
https://cleversonsacramento.wordpress.com/2011/10/17/mvc-ou-arquitetura-em-camadas/ 3/8
18/04/2022 11:57 MVC ou Arquitetura em Camadas? | Cleverson Sacramento

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).

Responder
2
Cleverson Sacramento on 17/10/2011 said:
Pede para ele colocar o ponto de vista aqui para a gente entender a ideia dele também.

Responder
3
Joselito on 17/10/2011 said:
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.

Responder
4
mariojp on 17/10/2011 said:
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.

Responder
5
Igor Cavalcanti Ramos on 17/10/2011 said:
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. =)

Responder
6
Cleverson Sacramento on 17/10/2011 said:
Valeu Igor!

Dá uma olhada neste material da Apple:

http://developer.apple.com/library/IOS/#documentation/Cocoa/Conceptual/CocoaFundamenta
ls/CocoaDesignPatterns/CocoaDesignPatterns.html#//apple_ref/doc/uid/TP40002974-CH6-SW1

Tem uma seção chamada “The Model-View-Controller Design Pattern”. Vai na subseção
“Model Objects Encapsulate Data and Basic Behaviors” que trata sobre dados (reforçando a
idéia de AlunoDAO ser Model).

Mas tudo é realmente uma questão de ponto de vista.

Responder
7
Salazar on 18/10/2011 said:
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.

https://cleversonsacramento.wordpress.com/2011/10/17/mvc-ou-arquitetura-em-camadas/ 4/8
18/04/2022 11:57 MVC ou Arquitetura em Camadas? | Cleverson Sacramento

Responder
8
Theo Franco (@theoffranco) on 18/10/2011 said:
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).

Responder
9
abraaoisvi on 19/10/2011 said:
Zyc pq vc não faz um artigo sobre DDD?

Responder
10
Cleverson Sacramento on 19/10/2011 said:
Não imaginei nada a respeito que eu pudesse contribuir. Se você escreveu ou vai escrever
alguma coisa, compartilha aqui conosco.

Para quem quer ter uma noção do que se trata: http://en.wikipedia.org/wiki/Domain-

driven_design

Responder
11
João Bulhões on 20/10/2011 said:
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

Responder
12
Cleverson Sacramento on 20/10/2011 said:
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?

Responder
13
Fábio on 21/10/2011 said:

https://cleversonsacramento.wordpress.com/2011/10/17/mvc-ou-arquitetura-em-camadas/ 5/8
18/04/2022 11:57 MVC ou Arquitetura em Camadas? | Cleverson Sacramento

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.

14
Alessandro Seixas on 24/10/2011 said:
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

Responder
15
Eduardo on 25/10/2011 said:
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.

Responder
16
Jader S. Santos on 14/12/2011 said:
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.

Responder
17
Augusto Neto on 06/07/2012 said:
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.

Responder
18
Victor Lippi on 22/10/2012 said:
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?

Responder
19
Cleverson Sacramento on 24/10/2012 said:
https://cleversonsacramento.wordpress.com/2011/10/17/mvc-ou-arquitetura-em-camadas/ 6/8
18/04/2022 11:57 MVC ou Arquitetura em Camadas? | Cleverson Sacramento

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.

Responder
20
Victor Lippi on 24/10/2012 said:
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?

21
Tiago Santana Machado on 07/04/2013 said:
Perfeito! Clariou muitas duvidas minha.

Obrigado amigo

Responder
22
Jeferaleite on 05/07/2013 said:
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!!!

Responder
23
guilherme on 02/10/2013 said:
continuo não vendo a diferença

Responder
24
Leonardo Leite on 20/08/2015 said:

https://cleversonsacramento.wordpress.com/2011/10/17/mvc-ou-arquitetura-em-camadas/ 7/8
18/04/2022 11:57 MVC ou Arquitetura em Camadas? | Cleverson Sacramento

Legal o post! Sobre camadas… só pra complementar:

http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html
;D

Responder
25
Rafael Odon on 03/09/2015 said:
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á!

Responder

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

https://cleversonsacramento.wordpress.com/2011/10/17/mvc-ou-arquitetura-em-camadas/ 8/8