Bom, só vamos esclarecer algumas coisas voltando as raízes…
O conceito Padrão de Projeto foi criado por Christopher Alexander na década de 70, ele foi é que define algumas características de arquitetura como encapsulamento, generalidade, equilíbrio e etc… de fato são abordagens bem genéricas, não exatamente são voltadas para a Computação.
Bom, Mas quem realmente inventou o MVC? O nome dele é Trygve M. H. Reenskaug (Lindo nome) em 1978/1979, Trygve criou o MVC na XEROX PARC originalmente com 4 termos: Model, View, Controller and Editor, Trygve defende dizendo que foi o primeiro a definir e publicar o padrão. http://heim.ifi.uio.no/~trygver/
Em 1987, Kent Beck e Ward Cunningham apresentaram alguns padrões para a construção de janelas na linguagem Smalltalk. Nos anos seguintes Beck, Cunningham e outros seguiram com o desenvolvimento desta idéias.
Por fim Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides os famosos GoF (Gang of Four) lançaram o livro Design Patterns: Elements of Reusable Object-Oriented Software em 1995, aqui podemos dizer que nasceu o nome Desing Patterns.
Bom… o que eu acredito, o MVC foi criado apenas como um Padrão de Arquitetura, o conceito Desing Pattern foi criado alguns anos depois, estes definem padrões a qual a motivação é padronizar para resolver problemas conhecidos.
Pode parecer um pouco lógico e claro assunto, porém aqui na empresa e entre amigos gerou muita discussão sobre o assunto,
Alguns falam que é um Desing Pattern, outros dizem que é apenas um modelo de arquitetura que pode ser seguido.
[/quote]
Existem diversas nomenclaturas. Design Pattern, Application Pattern , Arquitecture Pattern… mas todas significam coisas diferentes. Design Pattern é relacionado ao desenho da apliação. Eles focam mais na interação entre classes e como resolver problemas de comunicação entre classes. Arquitecture Pattern focam na interação entre aplicações e no esqueleto da aplicação. Que tecnologia usam e como as várias tecnologias podem ser encaixadas.
Application Patterns são padrões que visam resolver problemas das aplicações, como por exemplo, representar dinheiro de forma type safe ( padrão Money) .
MVC é um design pattern aplicado a uma só camada, normalmente a de visualização. Ele envolve outros design patterns como o observer ( na realidade o MVC pode ser entendido apenas como uma extensão do Observer, mas a sua fama fez dele um padrão à parte)
MVC não é um padrão de arquitetura . Não é uma forma de separar a aplicação em camadas. Isso são confusões mal entendidos do padrão. Se fossemos aplicar o padrão a camadas , a camada de modelo deveria lançar eventos para a camada view quando fosse alterada : ou seja, o banco deveria lançar eventos para a tela.
[/quote]
Oi taborda. Em resumo vc pode confirmar o link que postei logo acima…
Em uma aplicação desktop a camada de modelo pode lançar um evento para a view … não?
Model não é sinonimo de banco.[/quote]
Como?. EMHO, em uma app desktop… o model não consegue dizer para view: "oi view, eu me atualizei, se atualiza vc ai em cima tbm… ", pois o model não sabe nem que a view existe… O Framework Gênesis, do michel nascimento, usa algo bem parecido com isso, mas é sincronizado em forma dos binds.
Em uma aplicação desktop a camada de modelo pode lançar um evento para a view … não?
[/quote]
Não. Isso se chama : gambiarra.
É o componente de modelo do MVC que avisa a view do MVC. Como o M sabe que houve mudanças ? Isso cabe a cada aplicação decidir. É preciso entender que todos os componentes do MVC estão na mesma camada: apresentação.
Se MVC fosse um padrão arquitetural seria. Dai a analogia.
Exceto pelo fato de que não há cama da de modelo, sim. O model é observável e isso indica lançar eventos no caso de mudanças. A view e um dos seus observadores. Este é o coportamento mais difícil de reproduzir na web e é o que define o MVC desde 1978.
[quote=zinho]
Model não é sinonimo de banco.[/quote]
Exato. Model numa aplicação normal singnifica regras de negócio (domain model)+ infra (persist6encia e etc.) e estes objetos podem ser facilmente observáveis.
Na web, com um Data-Push (Producer/Consumer, Subscribe…) você resolve isso, porém seu cliente não pode ser tão simples, com um Flex da vida isso é tranquilo.
Por ser simples, falar do historico entre os modelos e uam rápida explicação de como cada um funciona em poucos paragrafos.
Há tempos tenho ele nos meus favoritos, foi inclusive a base do artigo que escrevi para a Java Magazine 54 http://www.milfont.org/tech/2008/02/12/java-magazine-54/
para explicar como funciona os novos modelos web 2 usando ajax para camuflar os efeitos do ambiente web
Acho que se enquadra no tipo: Padrão de Projeto de Arquitetura.
MVC visa separar a lógica de negócio, a visualização e acesso a dados em camadas distintas. Separar classes ou objetos pode ser considerado um efeito de arquitetura utilizando um modelo pré definifo, portanto, um design pattern.
Por isso, não deixa de ser um design pattern de arquitetura.
