MVC e Camadas
Muito simples: MVC não é relacionado a separação em camadas.
Parece simples. É simples. Mas causa tremenda confusão. Por alguma razão que desconheço muitas pessoas acham que MVC e separação em camadas são sinônimos. Talvez porque estão habituados a trabalhar com 3 camadas acham que as três letras caem que nem uma luva. Mas os sistemas podem ter qualquer numero de camadas. Aplicações modernas têm normalmente cinco camadas.
A confusão começa com a palavra “camada”. Normalmente as pessoas se referem à separação do sistema em regiões que se montam umas em cima de outras. Cada região dessas seria uma camada. O nome menos ambíguo para essas regiões é andar.
As pessoa entendem que existe uma camada perto do usuário que media a interação com ele (gráfica ou não), uma camada na outra ponta , perto dos dados que media a sua organização, transações, etc… e uma camada no meio que contém a lógica que responde aos comandos do usuário e produz alterações nos dados. O nome destas camadas são respetivamente : cliente, dominio e recursos. Hoje em dia esta simplicidade não mais se identifica com a estrutura de aplicações orientadas a objetos. Aplicações OO focam nas entidades do domínio e os bancos de dados são apenas repositórios burros. Além disso a tecnologia de repositórios ainda é a tecnologia usada pelas antigas aplicações orientadas a dados e como tal é preciso uma tradução entre os dois mundos. É ai que entra a camada de integração. Ela media entre o dominio e os recursos e entre o dominio em uma aplicação e o dominio de outras aplicações. Por outro lado as interfaces com o usuário se tornaram mais especializadas e inteligentes fornecendo pistas audiovisuais ao usuário que interage com a aplicação. Esta riqueza leva à constante alteração e embelezamento destas interfaces por questões de gosto ou ergonômicas o que obriga a uma camada que traduz tudo isso para a interação com o dominio. Esta é a camada de apresentação. Aplicações modernas orientadas a objetos utilizam-se destas cinco camadas.
O design pattern Model-View-Controler , mais conhecido como MVC trata de uma solução para design de componentes que atuam dentro de uma mesma camada , normalmente na de Cliente e/ou na de Apresentação. As outras camadas usam outros padrões. A de domínio utiliza ~principalmente os padrões Entity e Service e o de integração os padrões Mediator e Bridge.
O MVC trata da separação de responsabilidade entre as classes da camada e não da separação da responsabilidade entre camadas.
Por algum abuso de linguagem, desconhecimento ou falta de preocupação em verificar as fontes de informação as pessoas começaram a confundir MVC com separação em camadas. Já à partida deveria ser óbvio que 3 responsabilidades do M-V-C não dão conta das cinco ou mais responsabilidades atribuídas a camadas. Também deveria ser obvio que enquanto no MVC é necessária a presença das três partes, em separação de camadas não é obrigatória a presença de todas as camadas, apenas as necessárias. Além disso as camadas podem estar distribuídas em vários nodos enquanto que as classes que compõem uma implementação MVC têm que estar fisicamente associadas.
À partida seria óbvio supor que estas diferenças são óbvias e fortemente indicativas de que MVC e separação de camadas não são a mesma coisa, mas por alguma razão perdida no tempo muitas pessoas acham que é a mesma coisa. Pior que isso, ensinam a outros que é a mesma coisa. Espero que tenha deixado claro o absurdo que é misturar os dois conceitos.
Adendo (25/11/2009)
Parece que ainda não ficou claro que MVC não é sobre divisão em camadas (andares). Parece que 5 camadas podem caber em 3 letras. Alguém duvida que 5 não cabe em 3 ? Matemática elementar. Certo ? Pelos vistos não.
Ok, tem muito lixo pela internet confundindo as coisas. Mas tem muitas pessoas explicando direito [1,2]. Confundir as coisas é fácil. Não é preciso muito raciocínio para isso. Alguns pontos para pensar:
- MVC tem dependência triangular em que cada elemento faz e recebe chamadas do outro. Camadas são sobrepostas uma por cima da outra não havendo chamadas da camada baixa à camada alta.
- Tendo dependência triangular MVC só suporta 3 elementos. Não mais, não menos. Camadas suporta quantas forem necessárias. Basta empilhar mais uma e pronto.
- MVC é baseado em eventos (Padrão Observer). Comunicação entre camadas têm várias formas de ser feita.
- MVC é um Design Pattern. Camadas é um Padrão de Arquitetura. Bom, também é complexo para as pessoas distinguirem Design de Arquitetura, mas tem que ser mencionado.
Para os desatentos : MVC e Camadas não são conceitos de Java. São conceito de desenvolvimento de software. São válidos em qualquer linguagem.
Nunca vou entender como as pessoas conseguem dizer que um triângulo é uma pilha e uma pilha é um triângulo.
Sempre sou sacrificado quando tento explicar a diferença entre MVC e separação de camadas, mas não adianta…
A gente tenta. Quem dá o melhor que tem a mais não é obrigado. O pecado seria andar pelo mundo sabendo do erro e não tentar alertar as pessoas. Afinal, se queremos que a profissão tenha qualidade não podemos compatuar com esse tipo de asneira. Continue tentando…
Infelizmente Sergio, como já até discutido em fórum, sua explicação parece boa, mas sem sentido quando não há uma referência sólida. Se perguntarmos a quem fala camada em MVC, por traduzir layer cada parte, verá que eles passam referências, coisa que não fez e continua não fazendo.
Espero que seja mais científico do que prático, senão fica parecendo Martin Fowler mas, diferente de você, ele já tem nome em suas teorias.
PS: Faltou citar que essa dita “confusão”, que chamo de novo paradigma, surgiu após o DDD ficar famoso e não antes.
Você quer referencias. Eu lhe dei provas. No mínimo lhe dei evidências. Eu lhe dei o mais importante.
Cientificamente eu sou obrigado a lhe dar evidencias que falseiam a sua afirmação. Eu fiz isso. ninguem consegui falsear a afirmação de que MVC não é camadas. Alguem que prova ou evidencia que sim são camadas e que as evidencias que levantei não são válidas. A ciencia trabalha em cima de fatos, evidencias e provas.
Você que referencias. Isso não é científico. Quer referencias , procure-as. ninguem é obrigado a lhas dar. O que é obrigado a dar são as evidências e já dei bastantes (nenhum foi refutada).
Quer entender ? olhe os fatos. Quer ser um papagaio olhe as referencias.
Eu não alimento papagaios. Se quiser os fatos leia o que escrevi.
Olá Sérgio,
bacana o artigo. Outro artigo bastante referenciado sobre isso é o do Phillip Calçado: http://www.fragmental.com.br/wiki/index.php?title=MVC_e_Camadas
Nele, ele chega a falar o seguinte: “A partir do momento em que dividimos os nossos componentes em Camadas podemos aplicar o MVC nestas. Geralmente isto é feito definindo a Camada de Negócios como o Model, a Apresentação como a View. O componente Controller exige um pouco mais de controle. ”
Ou seja, o MVC não estaria restrito à camada de apresentação, apesar de estar predominantemente nesta.
Você tirou a conclusão certa lendo o texto errado. Parabéns.
Sim, vc tem razão, MVC pode ser usado em qualquer camada, sendo especialmente util na de apresentação. Mas ele é usado em uma camada por vez. Colocar o controlador numa camada e o view em outra e o model em outra é logicamente equivalente a identificar camada com cada responsabilidade do MVC, que é exatamente o que se quer negar. Tal equivalência não existe e dispersar as responsabilidades por camadas diferentes não faz sentido algum -até porque viola a interação entre camadas pois uma camada inferior não pode conhecer a superior. Veja bem, o MVC é baseado no padrão Observer, entre outros – como o autor indica – de forma que o M-V-C formam um triangulo em que uns são listeners dos outros. Este ciclo é impossivel de reproduzir em três camadas já que as mais inferiores não podem conhecer as superiores.
É fácil se confundir com MVC e Camadas e a prova está no texto do link que enviou.
Vou explicar melhor a minha opinião. Eu penso que, numa aplicação Swing, por exemplo, temos claramente o Swing implementando o MVC (ou uma variação deste, como alguns afirmam) na camada de apresentação.
Agora, pensemos numa aplicação Java web simples, que faça uso de um framework MVC, por exemplo. Neste caso, teremos na camada de apresentação a View (arquivos JSP) e o Controller (Servlet) – este último também poderia ser considerado camada de aplicação, mas vamos simplificar.
Agora, geralmente o Model é um objeto de domínio e, portanto, pertencente à camada de negócios. O Model será acionado e disponibilizado para ser acessado pela View (camada superior acessando inferior, tudo bem, não fere o princípio de camadas), que então irá renderizá-lo apropriadamente.
Meu ponto é esse: geralmente (não sempre), temos numa aplicação web (arquitetura Model 2) View/Controller na camada de apresentação e Model na camada de negócios. Ou Seja, o MVC está quase que completamente na camada de apresentação (daí o predominantemente).
Nada disso.
Os seus objetos de dominio não são o model dos frameworks mvc. O model desses frameworks é a triade application-session-request/response chamados genericamente de contextos. São estes caras que o view lê. O fato de dentro deles estar um objeto X que vc tb lê na view (tipo request.cliente.nome) não tornam X um objeto do model.
Comparando com Swing. TableModel é indiscutivelmente o model, mas os strings, e integer que ele devolve são apenas dados.
Se eles vêm de objetos entidade, não torna os objetos entidade parte do model do MVC do swing.
O problema é que o conjunto de entidades é chamado modelo, mas isso é uma nomenclatura antiquada. O termo correto é dominio. Classes de entidade do dominio, aparecem em todo o lugar pq são cross-layer, mas não precisaria ser assim. em muitos sistemas vc precisa criar viewhelpers para encapsular as entidades.
O servlet, o jsp, e o delegator do framework MVC estão todos na camada de apresentação.
Para o framework o servlet é o controler, o jsp a view e o delegator (action, controler, cada framework tem um nome para esses caras – mas são onde vc escreve as logicas) é apenas um strategy do controller. O model é sempre o contexto da requisição (application-session-request/response).
Para a aplicação o framework é uma API usada na camada de apresentação. Apenas isso.
Não confunda modelo de entidades com o “model” do MVC. Os nomes não são muito bons. O M do MVC deveria ser Mediador e não Model. Mais uma vez do tableModel. Ele atua como um mediador, porque na realidades os dados não estão nele.
Todo o MVC está na camada de apresentação. Quando vc chama um serviço do dominio ( um session do EJB, ou algo semelhante) vc está delegando à camada de negocio/dominio. Manipular os entities não caracteriza que vc está na camada de negocios.
Sergio, se é um cientista, tem que apresentar onde bolou suas teorias. Não nasceram com vc e se nasceram, tem que justificar o porque com mais gana.
Lamento, mas continuo com a prova do site da SUN, se alguém consegue o contrário, que fale com os gringos e não comigo.
PS: Eu acho errado você começar a chamar de Mediador em Model e de Andar em Layer. Primeiro porque isso demonstra pouca ou nenhuma experiência fora da linguagem Java e Model, em outros lugares são bem diferentes de apenas meros mediadores. Há casos de defensores de Models gordos e Controllers magros.
Acredito que precisa expandir um pouco seu conhecimento antes de criar teorias e ver que Django, Rails e outros frameworks tem visões diferentes do MVC do Java, que também é diferente do original.
PS: Site da SUN onde são referidos MVC como layers:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch2.html
Abraços e sucesso em sua luta.
Não fui eu que inventou o MVC portanto a teoria não é minha. Não tenho que justificar uma coisa que não fui eu que inventei.
MVC é só um. É um padrão , lembra? Padrões não têm cópias ou versões. O que acontece é que o MVC é um padrão complexo, na realidade é um conjunto de padrões mais simples como Observer, Mediator e Template Method que são amarrados de uma certa forma para produzir as três responsabilidades. Porque ele é complexo, existem várias formas de o implementar. Em cada linguagem certos construtos da linguagem são usados para simplificar a implementação. Mas o padrão é só um. Modelos gordos ou controladores magros não alteram o fato de haver modelos e controladores. E essa é que é a essência do padrão.
Eu não lamento que você fique com a sua opinião. Não estou tentando convencer você de nada. Estou apenas informando os fatos. A culpa de acreditar em certas coisas que lê e não em outras é totalmente sua e a responsabilidade da sua aliteracia também. Afinal vc diz que não concorda ( argumento de opinião) e não que eu estou errado. Como já falei, ninguem é obrigado a diminuir a burrice do próximo, apenas a ignorância. Talvez daqui a alguns anos, depois de ter trabalhado com MVC e ter implementado vários frameworks MVC como eu, vc entenda. Se não entender o problema é todinho seu. Eu faço a minha parte alertando. A minha consciencia está tranquila.
É cabível o comentário do outro Danilo, mesmo porque se você publica uma idéia e abre espaço para comentários nada mais normal que críticas apareçam. Creio que esse tipo de contestação só engrandece esse espaço (site, blog, ou qq outra coisa) porém a arrogância do Sr. Sérgio Taborda acabou com o alto nível do artigo e se realmente o Sr. se julga tão sabido por ter implementado vários frameworks MVC saiba que já vi muitos códigos de frameworks desse tipo e muitos deles estão bem aquém do que se espera…
sem mais.
Primeiro a ideia não é minha. Vocês têm que entender isso. Estou apenas expondo um fato. Existem várias outras pessoas que concordam. Não é culpa minha que vocês não concordem. Nem é minha intenção convencer ninguém. Por isso não tenho qualquer obrigação de prestar provas. Mas eu fiz mais que isso, eu mostrei porquê não são a mesma coisa. Vocês não estão convencidos ? Problema vosso. Querem colocar questões ? Estejam à vontade. Me culpar de arrogância é muito fácil para vocês que têm preguiça de consultar o google. Eu não me julgo sabido. Eu sei que vocês não sabem. É diferente.
Ninguém está falando dos códigos , e duvido que tenha visto os meus (se quiser olhe o código do MiddleHeaven). Estamos falando do conceito do MVC.
Afinal o que vocês querem ? que faça o vosso trabalho ?
Não demorou dois minutos no google para descobrir este texto :
Comparison with the MVC architecture
At first glance, the three tiers may seem similar to the MVC (Model View Controller) concept; however, topologically they are different. A fundamental rule in a three-tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middleware tier. Conceptually the three-tier architecture is linear. However, the MVC architecture is triangular: the View sends updates to the Controller, the Controller updates the Model, and the View gets updated directly from the Model.
From a historical perspective the three-tier architecture concept emerged in the 1990s from observations of distributed systems (e.g., web applications) where the client, middleware and data tiers ran on physically separate platforms. Whereas MVC comes from the previous decade (by work at Xerox PARC in the late 1970′s and early 1980′s) and is based on observations of applications that ran on a single graphical workstation; MVC was applied to distributed applications much later in its history (see Model 2)..
(http://en.wikipedia.org/wiki/Multitier_architecture)
vai querer que traduza também ?
Olá Sérgio, muito legal o artigo e bem esclarecedor, porém me surgiu uma dúvida em cima da referência que vc citou: “MVC was applied to distributed applications much later in its history (see Model 2)”, pelo que entendi o modelo 2 do MVC, ou MVC2 diz respeito a aplicações distribuídas, como fica isso nessa questão que vc falow que o MVC se enquadra em apenas uma camada?
O Modelo 2 diz respeito ao mecanismo de mvc usando em servlet containers. O Modelo 1 era um mecanismo implementado apenas usando servlets enquanto que o Modelo 2 usa servelts e jsp.
O fato do sistema ser distribuido é por causa do HTTP mas todo o processo MVC acontece no servlet container num unica jvm e numa unica camada (apresentação). Isso é explicito pelas tecnologias usadas que apenas rodam dentro do servlet container.
No inicio vc tinha um servlet para cada página. isto é muito ruim de gerenciar.
Então o modelo 1 foi introduzido. um servlet só recebe todas as requisições , processa a logica e delega a apresentação final para outro servlet. Este outro servlet apenas gera HTML.
Gerar HTML num servelt é muito chato e o JSP foi introduzido. Veja que o JSP ainda é um servlet tecncamente falando, mas para o programador é apenas um arquivo. Este é o modelo 2. Um servlet continua controlado todas as requisições,mas o display é feito por uma jsp.
Fique bem claro que o processamento da requisição não está distribuído.
O que está distribuido são as camadas.
Veja assim: a aplicação tem 5 camadas : cliente, apresentação, dominio, integração, recursos.
O cliente é o browser e a apesentação é feita com servlets. Então ha um protocolo de rede entre estas duas camadas.
Multiplos clientes acessam a mesma apresentação e é isso que significa distribuição.
Mas o fato da camada de cliente estar fisicamente separada da camada de apresentação, não tem nada a haver com o fato de que dentro da camada de apresentação ser usado MVC para processar as requisições.
Deste ponto de vista
Vi no livro de Martin Fowler, Padrões arquiteturais para aplicações corporativas, ele mesmo citando MVC, como o Model tendo a lógica de domínio, por isso me bato ainda nesse conceito, apesar de acreditar que o View e Controller, fica mesmo na apresentação, me bate a dúvida do Model apenas, já que até renomados autores, citam dessa forma, ou pelo menos fazem parecer dessa forma.
Repare bem : o model ter a logica do dominio e o model ser o dominio são coisas diferentes.
O model tem acesso ao dominio mas ele não é o dominio. Ele chama serviços do dominio, le e escreve entidades, etc..
Veja bem, o action do struts ou o controler do spring são o Model desses frameworks. Vc pode achar que é o controlador, mas não são.
Pense no que vc escreve nestas classes e verá a diferença entre o Model do MVC e o Modelo de Dominio.
Veja bem, o Modelo de Dominio também não é a Camada de Dominio. A Camada de Dominio contem mais coisas como serviços e repositorios, enquanto que o modelo de dominio são só as entidades.
Ok, o modelo de dominio faz parte da Camada de Dominio, junto com outras coisas, e não é a camada de domínio por si só, isso blz, agora pra mim o que tem a lógica de domínio é o modelo de domínio, e ele dizer que o model tem a lógica de domínio, sub-entendo que ele é o modelo de domínio, ou não? O livro detalha melhor mais por aqui http://martinfowler.com/eaaDev/uiArchs.html, da pra se entender a mesma coisa, apesar de não ter lido este artigo por completo. O que acha?
O que eu acho é muito simples. Modelo de Dominio é uma coisa, Camada/andar de Dominio é outra e Model do MVC é outra.
Quem tem a lógica de domínio para você? o Modelo de Domínio? Para mim é isso, o modelo de domínio tem a lógica de domínio, e o que entendi é que Fowler exemplificou o Model como possuidor da lógica de domínio, ou Martin Fowler, esta com uma visão diferente da sua, ou em algum ponto não estou conseguindo casar a mesma linguagem que os dois estão falando? Não estou indagando vc contra Martin Fowler, e sim querendo saber visões para formar minha opnião, então se ele tiver uma visão diferente da sua por favor, exponha. Obrigado por sempre responder.
A lógica, as regras de negocio, ficam na Camada de Dominio. A Camada de dominio é constituida pelo modelo de dominio , ou seja, o conjunto de entidades e seus relacionamentos,
mais os serviços que utilizam essas entidades , mais os repositorios que pesquisam e guardam essas entidades, mais os validadores necessários a validar os inputs e regras para as entidades , mais os value objets usados pelo dominio como sejam objetos de representação de dinheiro ou de unidades. Para implementar uma regra pode ser básico e ficar apenas um codigo numa destas classes, ou a regra implica em que várias destas classes tenham um pedaço de codigo que quando corridas todas juntas perfazem a regra.
O Model do MVC não é camada de dominio. Para começo de conversa ele não é uma camada (that’s the point). O model é formado por um conjunto de classes cujos contratos são definidos pelo MVC que estiver usando e que comunicam com a camada de dominio (normalmente serviços , validadores e repositorios) de forma a pode aproveitar-se das regras já implementadas lá. Além disso essas classes ainda implementam regras proprias da sua camada. Existem regras do tipo se o campo A está preenchido desabilida o campo B. Isto não são regras do dominio, são regras da apresentação. O Model do MVC funde estas duas regras de forma coerente para que a apresentação ao usuario ou à camada superior seja coerente com ambas. O TableModel do Siwing é muito bom exemplo. Para o básico em preciso de algum lugar onde pegar os dados. Isso é normalmente feito através de um serviço do dominio ou de um repositorio do dominio. Mas se a sua tabela for editável ( tipo excell) vc vai ter uma mireade de regras e validações de edição que têm que ficar contidas no TableModel, no renderizador de celulas ( pintar celulas de cor diferente conforem alguam regra) e em outros objetos auxiliares como o editor de celulas que só aceita valores válidos.
A camada de dominio não tem mecanismos para decidir cores, por exemplo. Isso tem que ser responsabilidade de alguem, e no MVC isso é responsabilidade do Model. O Model é o cerebro do MVC, o controler é apenas um automato que fornece um ciclo de vida de objetos e eventos sempre igual. É a manipulação do Model que faz a aplicação ter comportamento diferente.
Do ponto de vista da camada de apresentação, usando MVC, toda a logica de dominio está no Model. Mas quando se diz isso “está” significa que do ponto de vista da camada de apresentação recorre as classes do Model sempre que precisar invocar um comportamento para que o Model possa decidir com base nas regras de dominio. Mas essas regras não estão fisicamente lá porque estão delegadas em outra camada. A comparação seria para a camada de dominio usar um repositorio. Do ponto de vista dela as regras de pesquisa e leitura das entidades estão no repositorio e ela invoca o repositorio sempre que precisa executar essas regras (que ela não conhece). Mas de fato o repositorio delega essas regras à camada de integração onde estão os DAOs ou o Hibernate ou outro mecanismo ORM que faz o trabalho realmente. E este por sua vez delega ao JDBC que delega o SGDB. Esta cadeia de delegação é como o sistema funciona, mas do ponto de vista de cada camada ha objetos com responsabilidade encapsular os detalhes de como fazer algo. è por isso que conseguimos criar um sistema complexo usando peças simples.
O Model do MVC contém as regras de domínio no sentido que ele as encapsula, não que as têm fisicamente lá.
Obrigado pelos esclarecimentos, só pra constar nunca falei que o Model do MVC é uma camada (“Para começo de conversa ele não é uma camada (that’s the point).”). E a parte que talvez esclareça mais isso é onde vc diz (“O Model do MVC contém as regras de domínio no sentido que ele as encapsula, não que as têm fisicamente lá.”). Obrigado novamente
Struts 2 implementa MVC e não fica em uma única camada. Acho que não há o “todo mundo confunde”, vc é quem não entendeu oq é MVC.
Então em quantas e quais fica ?
Será que o struts fica na camada de dominio como o EJB ? será que fica na camada de integração como o hibernate ?
Será que fica na camada de cliente como o Swing ou o jQuery ?
Ah! Não se esqueça de apresentar referências onde se diz que o struts está em mais que uma camada. No Google não encontrei nada.
Sérgio, apesar de não estar na ponta da língua, fez sentido p/ seus conceitos e estou absorvendo-os… e concordo com vc que argumentos valem mais que referências.
O que eu noto é algo comum em alguem que tem muito conhecimento sobre determinado assunto. As coisas são TÃO óbvias pra você, que não entende como alguem não as entende…
Isso não acho legal, apesar de compreender…
Bom, eu via assim : se existe um argumento e a pessoa pode entendê-lo está tudo dito. Procurar por outras pessoas que dizem o mesmo é um exercicio futil.
Mas recentemente ouvi uma palesta da Linda Rising que me explicou porque isso não é suficente. Apenas 10% das pessoas se convencem por argumentação. Isso é um choque para mim porque deprecia a imagem que eu tinha do seu humano como animal racional. Mas fatos são fatos e se apenas 10% entende argumentos realmente não posso ser tão duro ao pedir que as pessoas simplesmente entendam os arguentos. Embora apenas 10% possam ser convencidos argumentos o meu objetivo no blog não é convencer niguém apenas chamar a atenção para a “ilogicidade” dos argumentos quotidianos. Mas acho que aprendi a lição. Se ha referencias, é melhor já colocá-las pois esse é grupo seguiinte às pessoas que entendem os argumentos : as que só entendem as referências. Isto é um pocuo triste porque o meu texto seria mais credivel se fosse referencia em outro texto, mais que pelo que está escrito nele e pior, mais que a realidade em si mesma.
Valeu.
Esse artigo também fala dessa diferença e está em português
http://fragmental.com.br/wiki/index.php?title=MVC_e_Camadas
Esse lnk já tinha sido enviado pelo Alexandre Gazola. Por favor, ver os comentários que fiz então.
Sergio, a data do post está antiga mais vamos la, estava lendo o seu artigo, concordo que MVC não tem nada haver com camadas.
Porem no site da sun : http://java.sun.com/blueprints/patterns/MVC-detailed.html
ele diz
”
Model – The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.
View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view’s responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.
Controller – The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
”
aqui ele diz que o model do mvc é a regra de negócio
imagine o modelo(normal) de uma aplicação de 3 camadas
aonde temos
apresentação (.xhtml, jsp, etc)
Negocio (Ejb(regra de negócio))
Persistencia (EAOs , DAOs)
como eu associo o mvc ai, eu sei que o mvc se aplica na camada de apresentação, mais no site da sun ele fala que o model (“fica, acessa”) a regra de negocio, mais a regra de negócio não está na camada de apresentação.
Não estou conseguindo assimilar isto.
E como eu associo o MVC na camada de apresentação?
no JSF eu posso falar que
.xhtml (view)
FacesContext (Controler)
ManagendBean (Model)
?????????????
mais o ManagendBean fica na camada de negócio certo?
Muito bom encontrar esse debate aqui. Estou estudando arquiteturas de software e também notei que existe algo de errado com a interpretação que a comunidade faz do padrão MVC.
Minha percepção é de que não há um consenso e que o consenso da maioria não traz os benefícios de manutebilidade e reusabilidade desejáveis quando se aplica o padrão MVC.
O pior, é que ainda existe muita gente implementando lógica de domínio dentro de view. Neste caso, tenho certeza que todos nós que postamos aqui concordamos ser uma aberração.
Eu também cheguei a escrever sobre essa confusão em torno do padrão MVC e confesso que eu tinha alguma convicção sobre meu pensamento mas após essa leitura fiquei com algumas dúvidas.
Para quem puder ler e me ajudar a ampliar meu entendimento sobre o padrão o link é:
http://brunogcarneiro.wordpress.com/2011/05/02/mvc-a-logica-de-dominio-nao-fica-no-controller/
***** SUGESTÃO FORTE PARA TODOS *****
Vamos tentar evitar discutir termos/palavras e tentar discutir idéias/conceitos. Entendem a diferença? Não foquem na palavra que a pessoa usa para se expressar mas tentem entender a idéia que ela quer passar. Fica evidente que existem por aí várias arquiteturas diferentes e que são designadas pelo mesmo nome: MVC.
Acho que a questão é: Como obter maior manutebilidade e reusabilidade. Eu sacrificaria sem dó até mesmo a definição original de mil novecentos e dinossauro do padrão MVC para ficar com uma definição mais moderna e mais útil.
[...] ler a partir daqui: http://santosrafael.wordpress.com/2010/12/06/o-que-model-view-controller-mvc/ http://sergiotaborda.javabuilding.com/2009/11/mvc-e-camadas/ [...]
Erick,
O model é a parte que comunica com o resto da aplicação. Esse “resto da aplicação” é genéricamente chamado de “regras de negocio” por vários autores. Entenda que isto não significa que o model tem as regras, ele comunica com quem tem. Em caso especial ele pode ter as regras em si mesmo, mas não é obrigartório que assim seja. Um naged bean, por exemplo, contém algumas regras simples, mas delega as mais completas a um EJB Stateless, por exemplo.
O ponto é o seguinte. Se as regras mudarem, qual dos três componentes vai ter que ser alterado num pior cenário ? O Model. apenas o model.
è por isso que a frase “The model represents enterprise data and the business rules that govern access to and updates of this data. ”
O model representa o os dados, as regras de negocio e a forma de acessa ambas. Dependendo do tipo de aplicação estes dados e regras podem ser acessados localmente, remotamente, ser delegados ou não.
sergiotaborda , entendi então o model ele acessa as regras de negocios
que inclui (MangendBean, EJBs, etc)
no caso do JSF
a camada de apresentação
.xhtml(View)
FacesContext(Controler)
?????????? (Model)
camada negócio
ManagendBean(isto fica na camada de négocio mesmo?)
Ejb
BO
etc
Minha dúvida é TEM COMO DEFINIR as partes do MVC como acima?aonde se encaixa cada parte? ou isso não existe,
Ex:
“O model é a parte que comunica com o resto da aplicação”
aonde fica o model?fisicamente
“Em caso especial ele pode ter as regras em si mesmo, mas não é obrigartório que assim seja. ”
Caso ele tenha as regras de negócio seria o managendBean por exemplo?
Sergio, muito interessante seu artigo, eu tenho uma dúvida simple
O model,,, é o ejb?
pois no site da sun ele fala que sim
Web-based clients such as browsers. JavaServer PagesTM (JSPTM) pages to render the view, Servlet as the controller, and Enterprise JavaBeansTM (EJBTM) components as the model. The Java Pet Store sample application illustrates this strategy.
Ola sergio , gostei muito do seu artigo, porem ainda tenho algumas dúvidas,,poderia me esclarecer?
minha dúvida é em relação ao model,,,
o model do mvc ele ACESSA as regras de negócio ou ele TEM as regras de negócios?
Se ele TEM eu posso falar que o model é o EJB por exemplo?
Se ele ACESSA qual parte seria?
deste ja muito obrigado
esqueci só para reforçar no site da sun ele afirma que o model é o ejb
Web-based clients such as browsers. JavaServer PagesTM (JSPTM) pages to render the view, Servlet as the controller, and Enterprise JavaBeansTM (EJBTM) components as the model. The Java Pet Store sample application illustrates this strategy.
Erick
Não. Isso não existe.
MVC são partes do seu software, não são tecnologias.
MVC não são camadas.
Por exemplo, EJB é composto de Session Beans, Message Beans e Entity Beans. Poderiamos dizer que os Entity são o modelo, e os session o controller, mas isso não é correto. Poderiamos , em vez, dizer, que o modelo do nosso sofware é suportado por um conjunto de session e entity beans, Contudo isto não significa que o EJB ( a tecnologia) seria o nosso model. Significa, que nesse caso, usariamos essa tecnologia para implementar o model.
Muitas pessoas confundem model com persistencia. Não é verdade. Os dados persistidos são uma parte do modelo, muito raramente um sistema não tem persistencia. Contudo a logicas que se aplicam sobre esses dados e/ou que lhes são origem tão são parte do modelo.
Já com isto respondeo à Jainaina. Podemos usar os ejb para construir o modelo , da mesma forma que podemos usar POJO ou OSGI não interessa a tecnologia que usamos, não isso que define se estamos falando de Model ou de MVC. O que define isso é a arquitetura do sistema. Se , num ssitema, POJO é usado isso é uma escolha, uma estrat[egia. Se usamos EJB é outra estratégia. Eu por exemplo não gosto de usar ejb e prefiro pojo, mas outras pessoas preferem usar ejb porque lhes dá a possibilidade de usar chamadas remotas de forma relativamente fácil. São estratégias.
A Sun, sempre definiu os EJB como parte do model quando falamos de aplicações enterprise. E é para isso que deveria servir essa tecnologia. Contudo, ejb sempre foi/ é muito mal compreendido. As pessoas sabem como usar, mas não quando usar. O objetivo do EJB é vc ter o coração do sistema , o negocio , ou seja, o modelo, de uma forma que possa ser acessada de diferents formas de forma a reaproveitar sempre as mesmas regras independentemente de quem for a visão ou o controlador. Mas esse sonho de write once run everywhere nunca viu a luz do dia, devido à falha de educação sobre quando e porque usar o ejb.
Janaina, nestas coisas de padrões temos que ter cuidado com o verbo “ser” um mesmo objeto pode “ser” muitas coisas dependendo de como olhamos.
Por outro lado vc tem que entende o principio de encapsulamento para entender o que eu vou dizer a seguir.
O modelo encapsula as regras. Portanto, tanto faz se eles as acessa ou se eles as tem. Do ponto de vista de quem usa o modelo , ele as têm. Indendentemente se na realidade da implementação eles as tem ou as acessa. Se vc desenhou seu sistema certo, vc sempre utiliza interfaces para chamar métodos que fazem coisas ( aka serviços). Ora, que chama a interface não sabe se a implementação que está por baixo, e que realmente faz o trabalho, o faz ali, ou manda fazer em outro lugar. Seja por proxy remoto, seja por delegação a outros objetos, isso não importa para quem chama o método.
O modelo representa esta parte que a interface representaria. Ou seja, por exemplo, se eu mando fazer uma trasferencia, tanto me importa que ela seja feita ali diretamente ou se que seja delegada a outro objeto ou até mesmo a um store procedure. O que me importa é que chamado aquele método eu tenha a garantia que a transferencia irá acontecer.
Portanto, por ponto de vista de quem usa o modelo, ele sempre TEM as regras. É dono das regras. Mas do ponto de vista de quem implementa o modelo, o desenvolvedor pode decidir implemenar as regras logo ali, ou delegar, etc.. e desse ponto de vista o modelo sempre acessa as regras de negocio.
Em um sisteam bem desenvolvido o modelo é sempre um conjunto de interfaces que podem ser implementadas de diferentes formas e/ou que têm alguma margem para o serem. Desse forma coisas como trasanção, segurança, acesso remoto, log, etc.. podem ser adicionados sem que o chamador saiba ou tenha que mudar seja o que for nas sua chamadas. Esta propriedade é chamada por muitos “Transparencia”, mas na realidade nada mais é que encapsulamento.
Lembre-se que o que a Sun (oracle) diz, é apenas uma das opções. Uma das estratégias possiveis. Vc não é obrigada a seguir essa. Mas se vc não conhece outras, pelo menos essa é um bom ponto de partida.
Agora me confundi rsrsrs..
Sergio você tinha fala que o MVC, se aplica somente na camada apresentação certo?
EJB fica na camada de negócio, como pode fala que o model é o EJB =S?
Então MVC não é aplicada somente da camada de apresentação?
no caso do framewok que implementa MVC , JSF por exemplo ele fica na camada de apresentação,, no caso ele JA IMPLEMENTA,,, agente precisava fazer mais alguma coisa para usar o MVC ou ja esta interno deste framework?
Obrigada por responder as perguntas…
O MVC é usado normalmente na camada de apresentação. Isso não significa que não pode usada em outras, é que é mais comum que seja na de apresentação e mais dificil usá-lo em outras. Quando me referi ao EJB me referi à implementação do modelo.
Por exemplo, conceptualmente o MVC está na camada de apresentação. Vamos falar de algo simples como um simples servlet controlando o fluxo e um jsp apresentado os resultados. O servlet tem que comunicar com as regras de negocio. Ele o faz através do modelo. Como falei, o modelo não são apenas os dados, mas também as interfaces. Então, se usarmos um serviço , por exemplo, ele é traduzivel por uma interface. A interface é o modelo. Estamos falando de um sistema bem separado que segue as boas práticas ( encapsulamento e programação para interfaces).
Ora, uma interface não me serve para nada se ninguem a implementar. VEja que a implmentação da interface, seja ela qual for e use qual tecnologia usar, não é modelo. O modelo é a interface.
No JSF vc implementa o managed bean. O managed bean é o modelo. Entenda que o JSF não a força a ter uma interface especifica para o bean, mas a interface que vc escolhe usar, é o seu modelo. O managed bean nunca vem implementado. Vc tem o implementar sempre. O que é óbvio, já que sendo o modelo, a tecnologia não tem como saber o que o programador irá fazer ou o que o programa precisa.
Entenda que a parte “modelo” do MVC é a parte que vc sempre implementa do zero. Pode ser que tenha que seguir alguma interfaces ou herdar alguma coisa especifica dependendo da tecnologia, mas nunca virá feito de “fábrica”.
No struts, por exemplo, as pessoas acham que estão implementando controlers, mas estão implmentando models. O controlador é o servlet do struts que poe tudo a funcionar.
Por outro lado é uma confusão vc dizer que o ejb está na camada de negocios. EJB é uma tecnologia, eu coloco-a onde quiser. Se usar usar web services via ejb com publicação direta vc está usando EJB como apresentação.
São três coisas distintas : tecnologia, padrão de projeto, implementação.
EJB é uma tencologia. Assim como jsf ou struts. MVC é um padrão de projeto.
Vou-lhe dar outro exemplo de MVC que nada tem que ver com ejb. O Jasper Reports. Ele é baseado em MVC. VC tem o view em xml que é o o que vc desenha com o oIReport. Tem o Model no JRDataSource (este é um caso em que vc precisa implementar uma interface especifica). O controler ? O proprio Jasper que sabe usar a view o modelo e produzir o resultado final. Vc pode mudar a view ou o model, mas nunca o controler. Vc usaria um session bean do ejb para implementar o
JRdataSOurce ? Eu não. Eu implementaria um serviço ejb que dado algum tipo de parametrs iria produzir o report e me o devolver.
è preciso manter o principio do padrã MVC separdo das teclogias que vc pode usar e separado da forma como vc irá realmente implementar. Vc pode sismplesmente nem sequer usar ejb. Tudo depende do objetivo do projeto.
O que é preciso ficar claro é que o Model é um contrato. A implementação desse contrato não é o model.
Sergio ficou bem mais claro agora, o que tava mais encanado é que para mim era CERTEZA que MVC era só na camada de apresentação, agora que vc falou que pode ser usados em outras camadas “deu um mortal no meu celebro kkkk”, mais ficou claro…
só uma coisa que ainda estou analizando é sobre o interfaces do ManagendBean que eu implento,,, isso é internamente né?
quando eu crio um managendBean automaticamente eu estou implementando uma inteface?
neste tutorial, da IBM
The MVC pattern’s purpose is to decouple Model (or data) from the presentation of the data (View). If your application has more than one presentation, you can can replace only the view layer and reuse code for the controller and model. Similarly, if you need to change a model, the view layer remains largely unaffected. Controller handles user actions that might result in changes in the model and updates to the views. When a user requests a JSF page, the request goes to FacesServlet. FacesServlet is the front controller servlet used in JSF. Like many other Web application frameworks, JSF uses the MVC pattern to decouple the view and the model. To handle user requests centrally, the controller servlet makes changes to the model and navigates users to views.
“FacesServlet is the controller element in the JSF framework which all user requests go through. FacesServlet examines user requests and calls various actions on the model using managed beans. Backing, or managed, beans are an example of the model. JSF user interface (UI) components represent the view layer. The MVC pattern helps to divide tasks among developers who have different skill sets so tasks can be carried out in parallel; that is, GUI designers can create JSF pages with rich UI components while back-end developers can create managed beans to write business-logic specific code.
”
http://www.ibm.com/developerworks/web/library/wa-dsgnpatjsf/index.html
Fala exatamente isto…
.xhtml (view)
FacesContext (controller)
ManagendBean (Model)
Ah é outra pergunta neste caso aonde
xhtml (view)
FacesContext (controller)
ManagendBean (Model)
o managendBean eu posso considerar ele em qual camada, a de negócio ou a de apresentação
Obrigada
Eu de novo , eu sei que é chato eu não parar de perguntar rsrs ,,mais poucas pessoas sabem REALMENTE oque é MVC
então vamos la
aqui vc fala
“O design pattern Model-View-Controler , mais conhecido como MVC trata de uma solução para design de componentes que atuam dentro de uma mesma camada , normalmente na de Cliente e/ou na de Apresentação”
quer dizer que se meu model for um EJB por exemplo e ficar na camada de negocio o conceito esta errado, porque vc fala que o mvc atua na mesma camada…
—————————————————-
outra pergunta espero que seja a ultima rsrsrs
você concorda com este artigo
http://www.oracle.com/technetwork/articles/javase/mvc-136693.html
?
aqui ele implementa o controle diferente do que o artigo da imb fala que o controle é interno
=s
Se vc usa considera o managedbean como parte da apresentação mas ele detém as regras de negocio, ele pertence à camada de negocio ?
Não. Porque ele nunca detém as regras de negocio. Ele detém as regras de apresentação. Por exemplo, é comum o managedbean conter alguma propriedade que depois será utilizada para ligar ou desligar algum campo , restringir o uso de algum campo, prover alguma validação extra, etc.
Por definição o managedbean não pertence à camada de negócios. A camada de negócios, ou melhor, a camada de dominio, está além da apresentação e deve funcionar independentemente da aresentação. ou seja, a camada de negocios deve ser reaproveitável para camadas de apresetnação diferentes. Ora, normalmente isto é feito via EJB. onde o objeto do modelo da apresentação invoca o session bean do EJB. E a partir dai saimos da apresentação e portanto do MVC. Lembre-se que o Modelo é uma porta para as camadas de baixo, e como tal, a implementação do modelo não é mais o modelo em si, mas uma substancia do modelo. O problema acontece quando vc usa um session bean como se fosse um managed bean. Isto é uma possibilidade tecnica, mas é uma má separação de responsabilidades (SoC) e encapsulamento. O modelo, quanto a mim, deve delegar ou consultar as camadas de baixo, de forma plugável. Ou seja, se a regra mudar eu não quero mudar a apresentação, apenas os objetos de negocio. Da mesma forma se a apresentação mudar, eu quero mudar apenas o objeto que implementa o modelo. Esta caminho-curto que algumas tecnologias permitem, não significa que é boa ideia. Neste caso, o objeto pertence Às duas camadas e isso pode ser muito perigoso. Eu, por mim, não vejo vantagem neste modelo, embora seja muito dificil encontrar uma implementação totalmente desacoplada.E tlv por isso, esta facilidade tecnologica seja “bem vinda” pelos programadores.
O artigo da oracle refere-se a swing um MVC gráfico. Não encontrei a referencia que falou, contudo, “controle interno” normalmente se refere ao fato que o controlador não se programa e já é “dado” por exemplo, se vc usa um JTable, vc implementa o TableModel. Se vc quer brincar mais, vc implementa renderers que são a parte alterável da view, mas o comportamento do componente JTale em si vc não muda, nem o algoritmo de renderização. Mesmo se vc implementar uma view diferente ( ou seja, criar um look and feel ) existe um algoritmo “master” que vc tem que seguir. Este algoritmo é que é o controler. É por isso que em swing vc consegue ter MVC e Componentes ao mesmo tempo. Entenda que isto não é comum e não é dado que tendo MVC tenha compontes e vice-versa. Por isso o swing é mais complexo que um MVC comum feito sem componentes. Para ficar claro, o Swing é um super MVC bem amarrado e estruturado que deixa alguns pontos para vc completar. Nomeadamente os models e os renderes. Os models não são o M do MVC mas sim a parte do M que vc pode extender. A mesma coisa os renderes que são a parte extensivel do V. O C não tem nenhum controle porque está embutido no design do Swing. O máximo que vc pode fazer é construir um componente.Que seria como encaixar 2 ou mais componentes para criar outro. Isso não é criar um C, é combinar diferentes C para criar outro. Ou seja, o Controlador, vc não mexe de fato, e por isso é dito que ele é interno. Mas entenda, que o Swing é muito mais do que MVC, entender swing apenas via MVC dá para ir longe, mas não para ir o caminho todo. Por outro lado, usar Swing para entender MVC pode confundir algumas pessoas.
Olhando as implementações MVC em geral o C sempre é pre-definido e pouco alterável pelo programador final. Algumas implementações deixam algumas interfaces ou coisa assim que pode ser usada para definar alguns passos do controlador, mas não para mudar o controlador completamente. E isto faz sentido porque o C é que é o cara que contém o algoritmo que faz as coisa funcionar e o algoritmo é apenas um. O algoritmo de controle.
Ola sergio, mtu obrigado por estar me ajudando a entender tem uma coisa que não entra na minha cabeça
o model….esse cara que não estou entendendo
”
O MVC é usado normalmente na camada de apresentação. Isso não significa que não pode usada em outras, é que é mais comum que seja na de apresentação e mais dificil usá-lo em outras. Quando me referi ao EJB me referi à implementação do modelo.
”
Primeira dúvida a implementação do Model então não é o managendBean?
http://www.ibm.com/developerworks/web/library/wa-dsgnpatjsf/index.html
aqui ele fala que o model é o managendBean =s
mais no site da sun ele fala que model contem as regras de negocio
“Model – The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.
”
http://java.sun.com/blueprints/patterns/MVC-detailed.html
se vc fala que MangedBean não esta na camada de negocio como ele pode ser o model que o artigo da IBM fala?
Segunda dúvida ,, eu não consigo intender o que vc fala abaixo
”
Lembre-se que o Modelo é uma porta para as camadas de baixo, e como tal, a implementação do modelo não é mais o modelo em si, mas uma substancia do modelo
”
Como assim a implementacao do modelo não é mais o modelo em si,, não consigo entrar isso na minha cabeça
qual parte “fisicamente” que serio o model então?
Este é o problema, vc está tentando encontrar uma classe ou objeto que seja o modelo. Vc está tentando encontrar o que “fisicamente” é o modelo. É como tentar encontrar o que fisicamente é a inteligencia ou o amor. A pergunta está errada. A unica resposta a isso é : o modelo não é fisico.
Como lhe disse antes o modelo é a interface, o contrato, o protocolo. Não a implementação.
É por estas e por outras que as pessoas não tem que ser uma unica classe/objeto. Normalmente não é. VEja o exemplo do TebleModel do swing. É uma interface. Um contrato. Um contrato que o controlador espera que o programador implemente a gosto, mas que tb espera que cumpra certas regras conforme descrito no javadoc. Isso é o modelo. Um protocolo entre o controlador e o programador final.
O que pertence em camadas são as implementações destas coisas.
Se vc implmenta um TableModel normalmente vc implementa um objeto qu implementa a interface e depois se necessário esse objeto chama outros objetos (padrao adapter) em que camada estamos ? na de apresentação. E o objeto chamado está em que camada ? Depende. Pode estar na camada de dominio ou ser um Business Delegator que ainda está na camada de apresentação. Tudo depende de como se implementa. Portanto, o Modelo, conceptualmente está sempre na mesma camada que o V e o C porque os contratos, as interfaces, são sempre usadas nesse nivel. As implementações dessas interfaces, por outro lado, podem estar ou não na mesma camada. Tudo depende das escolhas que o desenvolvedor fez.
Veja assim : não é importante em que camada está a implementação do modelo. E o modelo em si, por definição, está na mesma camada que o V e o C.
Se ainda não entendeu, tente pensar no View. em que camada ele fica ? e o Controler ? Vc vai chegar á conclusão que não faz sentido perguntar isso, por eles todos estão na mesma camada. Seja ela qual for.
Estou pensando que seria melhor escrever outro artigo com alguns bonecos para exemplificar melhor. Se ainda é confuso, me dê uma semana e fique ligada no blog.
Obrigado pelo interesse.
Sergio, intendi que o modelo não é fisico, mais existe uma interface certo?
Como lhe disse antes o modelo é a interface, o contrato, o protocolo. Não a implementação
mesmo assim sergio a interface temque está em algum lugar..
no caso do jsf, esta interface fica aonde?
é só isso que nao intendo, porque vc fala que não tem fisicamente, mais a interface é fisica, temque esta definida em algum lugar..
okey caso escreve outro artigo estarei de olho
obrigada
Entenda que não estou falando de interface “construto do java que se define em um arquivo com a palavra interface” e sim interface como o conjunto de métodos, suas assinaturas e comportamento esperado. Aquilo que se chama também contrato.
Janaina, tentei esclarecer melhor em um novo post. Espero que ajude.
Sergio, consegui entender melhor, é um assunto que para analise superficial é simples, porem se for afundo gera muitas duvidas e se torna complexo,,, agora tenho um melhor intendimento do assunto,,não vou dizer 100% mais melhorou muito.
Quero agradece pela atenção é a PACIENCIA .
MUITO OBRIGADA
JANAINA
Oi Sérgio,
Esta visão de MVC que está no link abaixo então, está equivocada ?
http://pt.wikipedia.org/wiki/MVC
Mais uma pergunta: De onde você acredita que saiu a confusão entre o padrão MVC e divisão em camadas ?
Abraços.
Fora a parte que considera como um padrão arquitetural, o resto é mais ou menos a mesma lenga-lenga de sempre.
Para mim padrões de arquitetura são coisas mais abstratas que MVC. Por exemplo, SOA ou Publish/Subscriber … mas pronto, como digo no texto, é dificil explicar a diferença entre design pattern e padrão de arquitetura.
A confusão não sei de onde saiu ( no texto exploro algumas opções possíveis). Agora, eu sei como se alastrou : o cego ensinando o surdo. Pessoas que acham que sabem ensinando pessoas que acham que compreendem. E ai vira essa bagunça.
Claro que, para a esmagadora maioria das pessoas é irrelevante o que MVC realmente é, mas para pessoa que fazem frameworks e trabalham com estrutura de sistemas é bastante importante ter os conceitos bem alicerçados. Alguns sites de renome e algumas revistas sem uma editorial forte deixam passar muita bobagem , igual ao professor do ensino médio que apenas repete o que sabe sem explicar o por quê.
I admit, I have not been on sergiotaborda.javabuilding.com in a long time however it was another joy to see It is such an important topic and ignored by so many, even professionals. I thank you to help making people more aware of possible issues.