MVC
ModelViewController (MVC) é um modelo de desenvolvimento de interface do usuário de computador que separa a lógica de apresentação da informação e a interação do usuário; O modelo contém dados de aplicativos e lógica de negócios; O controlador é responsável por converter a entrada do usuário em comandos e passá -lo para modelar e visualizar; Esta é a explicação da Wikipedia;
Este modelo foi originalmente projetado por Trygve Reenskaug ao trabalhar com SmallTalk-80 (1979) e foi chamado de model-view-controller-editor; Mais tarde, através da introdução aprofundada do livro "Padrões de design: elementos de software reutilizável orientado a objetos", o MVC se tornou completamente popular;
Entenda as responsabilidades de compensar as três partes do MVC e o que as estruturas JavaScript existentes nos fornecem para que possamos usar melhor essas estruturas. Em seguida, passaremos primeiro as três partes que compõem o MVC para saber quais as responsabilidades de cada parte recebem um código de demonstração com backbone como exemplo].
Modelo
Modelo gerencia dados de aplicativos. Quando os dados do modelo mudarem, seu ouvinte será notificado [provavelmente uma visualização]. Depois de receber a notificação, o ouvinte fará alterações correspondentes.
Visualizar
A visualização é uma representação visual do modelo de estado atual. A visualização observará as alterações do modelo e é notificada quando o modelo muda e permite que a visualização se atualize. Geralmente, usaremos o mecanismo de modelo para renderizar o modelo na visualização;
Controladores
Os controladores são um mediador entre modelos e vistas. Seu trabalho é atualizar a visualização quando o modelo mudar e atualizar o modelo quando o usuário operar a visualização.
Comparação de Estrutura Javascipt MVC
Pessoas diferentes têm métodos de comparação diferentes, a chave depende do que você presta atenção:
1. Se você prestar mais atenção aos detalhes do roteamento de URL da estrutura, armazenamento de dados, visualizar implementação etc., você pode se concentrar nisso, JavaScript Throne: Framework Sword;
2. Se você prestar mais atenção a exemplos específicos da estrutura, existe um projeto de código aberto aqui que usa diferentes estruturas JavaScript MVC para a mesma demonstração. Você pode ver claramente as diferenças nas aplicações específicas de cada estrutura. Aqui está o site oficial do TODOMVC
Os benefícios do MVC trazem para nós:
1. Fácil de manter
2. A dissociação da visualização do modelo significa que a lógica de negócios pode ser melhor testada.
3. O código pode ser reutilizado melhor
4. O desenvolvimento modular pode tornar a divisão do trabalho mais clara, algumas pessoas se concentram na lógica de negócios e algumas pessoas se concentram na interface do usuário.
5. Depois de revisar o modelo clássico do MVC, entendemos o conceito de camadas na aplicação e as responsabilidades de cada camada. Ao mesmo tempo, devemos ser capazes de identificar as diferenças entre todas as estruturas do JavaScript MVC e o modelo clássico do MVC que explicamos. Dessa forma, ao escolher a estrutura do MVC, devemos nos concentrar em como modelos, visualizações, controladores são implementados e até como implementar códigos específicos, de modo a nos ajudar a escolher melhor a estrutura JavaScript MVC mais adequada.
Mvvm
O nome completo do MVVM é o modelo View ViewModel. Esse modelo arquitetônico foi originalmente proposto pelo Martinfowler da Microsoft como a especificação do modelo de design da camada de apresentação da Microsoft. É um derivado do modelo MVC. O foco do modelo MVVM está nas plataformas de desenvolvimento da interface do usuário que podem suportar orientação a eventos, como HTML5, [2] [3] Windowspresentation Foundation (WPF), Silverlight e T ZK Framework, Adobe Flex.
A maior parte da implementação deste modelo é separada de outras camadas, declarando a ligação dos dados na camada de visualização, o que facilita a divisão do trabalho entre desenvolvedores de front-end e desenvolvedores de back-end. Os desenvolvedores de front-end escrevem dados vinculados para o ViewModel na tag HTML. Modelo e ViewModel são desenvolvedores de back-end que mantêm essas duas camadas através da lógica do desenvolvimento de aplicativos.
Nos últimos anos, o modelo MVVM começou a ser implementado em JavaScript. Atualmente, estruturas relativamente maduras incluem KnockoutJs, Kendo MVVM e Knockback.js. Vamos tomar knockoutjs como exemplo para ver as responsabilidades específicas e os códigos de exemplo de cada parte do modelo MVVM e, ao mesmo tempo, entender as vantagens e desvantagens do uso desse modelo para se desenvolver.
Modelo
Como outros membros da família MV*, o modelo representa dados em um campo ou dados específicos necessários para o aplicativo, dados típicos específicos de campo, como informações do usuário [nome do usuário, avatar, email, número de telefone] ou informações musicais [nome da música, ano de lançamento, álbum];
O modelo se concentra apenas nas informações dos dados e não se importa com nenhum comportamento; Ele não forma dados ou afeta a exibição de dados no navegador, o que não é de sua responsabilidade; Os dados de formatação são a tarefa da camada de visualização e a camada lógica de negócios é encapsulada no modelo de exibição para interagir com o modelo.
Um comportamento mais inesperado feito na camada do modelo é verificar os dados. Por exemplo, quando o usuário inserir o email, determine se o formato de email está correto.
Nos knockoutjs, o modelo é basicamente implementado de acordo com a definição acima, mas haverá serviço de servidor de chamada AJAX para ler e gravar dados do modelo.
Visualizar
A visualização refere -se à parte do aplicativo que interage diretamente com o usuário. É uma interface interativa para representar o estado do viewmodel. A visão é considerada ativa e não passiva? Essa frase significa que a visão passiva não se importa com o domínio do modelo no aplicativo, e o domínio do modelo é mantido no controlador; A visão ativa do MVVM inclui ligação de dados, eventos e o comportamento do modelo e do ViewModel precisa ser compreendido. Embora esses comportamentos possam corresponder aos atributos, a visão ainda precisa responder ao evento do ViewModel, e a visualização não é responsável por controlar o estado.
A camada de visualização do KnockoutJs é um documento HTML simples, que estará associado à declaração de dados do ViewModel. Ao mesmo tempo, a camada de visualização do KnockoutJS exibe os dados obtidos do ViewModel, passa comandos para o ViewModel e atualiza o estado alterado do ViewModel.
ViewModel
Pode -se considerar que o ViewModel é um controlador usado especialmente para conversão de dados. Ele pode converter as informações no modelo em informações na visualização e, ao mesmo tempo, passe os comandos da visualização para o modelo;
Nesse sentido, o ViewModel se parece mais com um modelo, mas controla grande parte da lógica de exibição da visualização. Ao mesmo tempo, o ViewModel também expõe alguns métodos para manter o estado da visão e atualizar o modelo de acordo com o comportamento e os eventos da visualização;
Em resumo, o ViewModel está localizado atrás da camada da interface do usuário e a exposição de dados à exibição pode ser considerada como fonte de dados e comportamento da camada de visualização;
Os knockoutjs interpretam os viewmodels como a exibição de dados e comportamentos expressos na interface do usuário. Não é um modelo de dados que precisa ser persistido, mas pode conter os dados armazenados pelo usuário. O ViewModels da Knockout é implementado usando objetos JavaScript e não há necessidade de se preocupar com tags HTML. Esse método abstrato pode simplificar sua implementação.
vantagem:
1.MVVM facilita o desenvolvimento paralelo, para que o desenvolvimento do front-end e os desenvolvedores de back-end não se afetem.
2. Resumo da camada de visão, reduzindo a lógica de negócios no código
3.ViewModel é mais fácil de testar do que orientado para eventos
4. O teste do ViewModel não precisa se preocupar com a automação e interação da interface do usuário
deficiência:
1. Para uma interface do usuário simples, usar MVVM é um pouco pesado demais
2. A ligação dos dados declarativos não é propícia à depuração, porque o código imperativo pode facilmente definir pontos de interrupção, e esse modo não é propício a definir esses pontos de interrupção.
3. A ligação de dados pode criar muita manutenção de livros em aplicações não triviais. Você também não deseja acabar com uma situação mais complexa na qual a ligação é mais complicada que o objeto ligado.
4. Em grandes aplicações, é difícil projetar a camada de modelos de visualizações antes de obter um grande número de generalizações.