O MVC se aplica apenas à web

É quase instantâneo sempre que falo com os desenvolvedores sobre o Model View Controller ( MVC ), eles dizem que você solicita uma URL, o servidor cria uma entidade (MODEL) e fornece uma representação visual desse modelo.

• Então, isso significa que o MVC é apenas para a Web ou eu tenho conhecido pessoas que são apenas desenvolvedores que empregam o MVC para criar aplicativos da Web?

• Existem usos para o MVC em aplicativos de estilo de área de trabalho?

• Eu, pelo menos sou novo em paradigma e gostaria de saber de qualquer superconjunto para MVC

MVC é um padrão. Os padrões se aplicam a toda a programação. O MVC funciona muito bem em um contexto da web.

Como o gnat aponta, basta dar uma olhada na tag mvc e você verá vários exemplos dela sendo implementados.

Considerando que o MVC é de 1977 e a web foi inventada apenas em 1991, deve ser bastante óbvio que o MVC não é apenas para a web.

Não, o desenvolvimento para OS X e iOS usa o padrão Model View Controller.

Faça a pergunta em um ambiente Microsoft e muitas pessoas assumirão que você quer dizer Asp.Net MVC, que é uma implementação MVC especificamente para a web.

Infelizmente, há muitas pessoas que não percebem que essa é uma implementação do padrão MVC e pensam que são termos intercambiáveis, o que leva a uma suposição de "apenas web".

Pelo menos até onde eu sei, a primeira implementação do MVC foi no Smalltalk. Definitivamente estava presente no Smalltalk-80. Embora eu não tenha nenhuma documentação útil para provar isso, acredito que (ou algo parecido) esteja no Smalltalk há alguns anos.

A maioria das estruturas da GUI OO inclui pelo menos alguma variante do MVC. Não tenho certeza, no entanto, exatamente o que "superconjunto" significaria nesse caso. É um pouco difícil dizer se alguma variante é um superconjunto, subconjunto ou par do MVC, mas eu tenderia a considerar a maioria deles pares.

De qualquer forma, muitos deles (a maioria?) Foram usados ​​para desenvolvimento de desktops, não para web. Graças a algumas patentes antigas da AT&T, a maioria dos sistemas de janelas exige que os programas possam gerar novamente visualizações sob demanda. Isso (quase) força pelo menos algum grau de separação entre o código que mantém o estado atual (o modelo) e o código que exibe esse estado (a visualização). Isso ainda deixa muito espaço para variação em 1) o grau em que a funcionalidade do controlador é isolada e 2) os detalhes exatos de onde desenhar as linhas entre cada uma das peças principais.

Não, aplica-se mesmo a aplicativos independentes. Exemplo O Java Swing segue o MVC.

Portanto, existem muitos padrões de design diferentes nessa área.

• Apresentador da vista de modelo (mvp)
• Apresentador de exibição de vista de modelo (mvvp)
• Model View Controller
• Model 2

e assim por diante. Ao longo dos anos, eles foram entrelaçados, misturados, alterados e aplicados em uma ampla variedade de contextos. O ponto importante aqui é que o padrão de design do MVC de 1977 mudou bastante e não é mais o padrão de design usado pelos frameworks da Web do lado do servidor. Como um exemplo na implementação original do smalltalk, o Model observaria a exibição de alterações, o que não é mais o caso, pois o servidor simplesmente não pode observar os elementos html no navegador do usuário. Em vez disso, se a visualização mudar, ela enviará uma solicitação ao controlador que atualizará a visualização. Novamente, a implementação original do MVC não é seguida, pois uma atualização no modelo implica que todas as visualizações dependentes do modelo sejam atualizadas.

As estruturas modernas da Web seguem uma arquitetura simples de três camadas, também conhecida como arquitetura Modelo 2.

É claro que existem exemplos de arquiteturas MVC reais na Web, mas geralmente são apenas do lado do cliente, conectados a um servidor que segue a arquitetura do Modelo 2, pois as visualizações são xml e json e não são observadas para alterações. Exemplos de arquiteturas mvc puras do lado do cliente são Sencha Touch e Sproutcore.

Se você possui MVC no navegador, mvc como no servidor e mvc como camada de dados, você tem uma implementação hierárquica de mvc.

Nota. Eu só falei sobre estruturas da Web, outras implementações do MVC, como java swing e Flex, têm outras diferenças de implementação.

Uma coisa que você deve saber é que existem tantos tipos de MVC quanto estruturas que pretendem implementar o MVC.

A maioria concorda com o fato de que o Modelo possui algum estado e o View o processa. Mas o controlador tem papéis muito diferentes.

No Smalltalk, onde foi descrito pela primeira vez, o Modelo é o núcleo de seus aplicativos, dados e métodos de negócios. O View é uma representação gráfica do estado do aplicativo (também conhecido como Modelo), e o Controller gerencia os eventos de entrada do usuário, mouse e teclado. O Controller, por exemplo, roteia os eventos do teclado para o elemento view que tem o foco.

Nas páginas .jsp, o Model é principalmente dados, a View renderiza esse Model para HTML e o Controller faz o roteamento do Model para a View apropriada para renderizá-lo.

Portanto, para responder sua pergunta, embora o MVC seja usado em aplicativos independentes (Java, .Net, Flex) e na web (páginas jsp), é uma coisa muito diferente. Isso significa que o MVC que você conhece não é usado em aplicativos independentes.