índice
MVC
O
WebForm Model-View-Controller surgiu repentinamente quando o ASP ainda estava lutando, assim como o MVC apareceu repentinamente quando o WebForm ainda estava lutando. Claro, o MVC de que estou falando aqui ainda é o MVC original, porque o MVC desenvolveu muitos ramos diferentes enquanto ainda discutimos.
Uma coisa que acredito que todos concordam é que MVC, MVP, MVVM, Code Behind, etc. que estamos discutindo hoje são todos derivados da ideia e do propósito de diferenciação funcional e planejamento. MVC não é o começo deles, mas um bom começo .
Acredito que o modelo MVC seja muito familiar a todos e fácil de encontrar. Vamos usar uma imagem de uma enciclopédia aqui:
O que podemos ver é que a interface é atribuída à Visualização, os dados são atribuídos ao Modelo da operadora e "transportados" pelo Modelo, o negócio está concentrado no Controlador e os eventos que promovem o negócio são interagidos pelo usuário e a Visualização e lançados no Controlador por meio da Visualização.
Claro, existem muitas implementações, e cada detalhe é diferente, então só posso falar sobre MVC em geral. Uma das desvantagens do MVC é que não há uma definição clara, portanto, diferentes implementações (como Struts e ASP.NET MVC) são diferentes em detalhes.
O que precisamos saber é que MVC não é um resultado "inevitável" como algumas das coisas mencionadas acima, é uma solução em uma série de problemas inevitáveis e é uma solução imperfeita. É fácil errar quando seguimos nosso raciocínio até certo ponto, acreditando que só existe um caminho e ignoramos outras possibilidades (estima-se que essa também seja a causa de muitas brigas). Além disso, há um contexto quando discutimos algo imperfeito, então, por favor, não diga "Eu disse que tem uma única cor e então você pinta com uma cor e prova que estou errado."
O processo geral do MVC é assim:View（界面）触发事件--》Controller（业务）处理了业务，然后触发了数据更新--》不知道谁更新了Model的数据--》Model（带着数据）回到了View--》View更新数据
Não vou declarar os princípios, práticas, etc. do MVC mais aqui, porque é muito longo.
Para saber como usar o framework MVC, consulte este blog:
[Unity3D] Como usar o framework MVC no Unity3d
MVP
Model-View-Presenter e alguns derivados,
como raciocinamos antes 分化是一种需求的必然结果，但却没有个一个确定的结果, como problemas de Code Behind e Code Block e assim por diante.
O MVC divide o trabalho relacionado à IU em três partes de acordo com a demanda, o que tem se mostrado compreensível na prática. No entanto, sua relação triangular é considerada por alguns como trazendo alguns problemas, ou deveria ser dito que eles têm uma solução "melhor".
A manutenção era muito direta quando havia apenas Code Behind e Code Block, no mesmo trecho de código ou no mesmo evento relacionado. O problema do relacionamento do triângulo é a manutenção. No MVC, quando você muda, você precisa manter três objetos e três interações ao mesmo tempo, o que obviamente complica as coisas.
Mencionamos anteriormente que, com a Lei de Moore, a demanda por software muda constantemente e se torna enorme. À medida que a demanda torna-se enorme, as mudanças na demanda tornam-se frequentes, este é um problema que já apareceu inúmeras vezes e vai aparecer inúmeras vezes, por isso precisa de uma solução, mesmo que não possa ser resolvido.
A fim de atender às mudanças na demanda, de "Mitologia Homem-Mês" a Agile a DDD, não é um problema que resolvemos, mas um problema que estamos resolvendo. Em termos de modo UI e MVC, é para otimizar ou substituir o modo MVC, um dos quais é o modo Model-View-Presenter (MVP).
Vamos dar uma olhada nos diagramas de dois modos MVP:
As duas imagens são diferentes, mas a ideia de melhorar o MVC é a mesma: cortar a conexão entre View e Model, permitindo que View interaja apenas com Presenter (controlador original), reduzindo o número de objetos que precisam ser mantidos durante mudanças de demanda.
Esta abordagem está de acordo com nossas expectativas, porque tendemos a:
用更低的成本解决问题
用更容易理解的方式解决问题
Em muitos casos, não é porque um modelo não seja bom, mas porque as pessoas não conseguem implementá-lo, por exemplo, não é fácil de entender, vamos escolher o caminho que é mais fácil de entender. Os computadores contam com a Lei de Moore para resolver problemas com números crescentes, enquanto os humanos resolvem problemas com mudanças nos métodos. Além disso, por razões objetivas, não somos bons em manter vários objetos e no relacionamento entre vários objetos, então mudamos ou simplificamos essa abordagem.
O MVP define a interface entre o Presenter e o View, de forma que algumas possam ser desenvolvidas de forma independente de acordo com o protocolo de interface existente, de modo a resolver o problema de mudanças frequentes nos requisitos de interface. As duas imagens acima têm interfaces, mas os detalhes de implementação e uso das interfaces são diferentes, mas as ideias são as mesmas.
O que quero mencionar aqui é que, na verdade, a mudança mais frequente na demanda não é necessariamente a interface mais próxima do usuário, mas é basicamente certo que a interface mais próxima do usuário é aquela que precisa ser alterada com mais frequência por causa das mudanças na demanda. Claro, se o View for uma API em vez de uma UI, é outro assunto.
Existem também alguns usados para "resolver" essa deficiência do MVC, como: ASP.NET MVC ViewBag, delegado Cocoa. Todos eles existem para simplificar o problema de atualização de dados, incluindo MVVM.
MVVM
Model-View-ViewModel
primeiro olhe diretamente no diagrama Model-View-ViewModel (MVVM):
Pela foto, é mais simples do que MVP, quanto mais MVC. Pessoalmente, não acho que o MVVM evoluiu do MVP. Só acho que é uma solução de modelo de IU "melhor" que surgiu após o MVP, mas é mais fácil explicar o problema com o MVP.
ViewModel é aproximadamente o apresentador do MVP e o controlador do MVC, e não há interface MVP entre View e ViewModel, mas interação direta, usando "vinculação" de dados para permitir que eventos de atualização de dados não exijam que os desenvolvedores escrevam manualmente Casos de uso especiais, mas automaticamente bidirecionais sincronização. Você pode pensar na vinculação de dados como o modo Observador ou o modo Publicar / Assinar.O princípio é usar uma forma unificada e centralizada para obter atualizações de dados frequentes que precisam ser implementadas.
Comparado com o MVP, o MVVM não só simplifica a dependência entre o negócio e a interface, mas também otimiza a solução para atualização frequente de dados e pode até ser considerado um modo de solução eficaz.
Neste ponto, podemos entender porque muitas pessoas pensam que o MVVM é o melhor modo e não há ninguém. Mas, na verdade, o MVVM também depende da "situação especial" que dissemos até agora.
Obviamente, a prática mais elegante e representativa é o Windows Presentation Foundation (WPF).
Resumindo:
No framework MVC, M e V estão intimamente relacionados, enquanto no MVP, V e M não têm nada a ver um com o outro, o que é equivalente a "isolamento". Ou seja, se você quiser alterar V ou M no MVP, isso afetará apenas P e o MVC afetará um ao outro. Portanto, o MVP é mais dissociado do que o MVC.
A lógica do evento no MVVM é realmente executada na VM. V é exatamente assim. O gatilho do evento será imediatamente enviado para a VM para processamento. Após o processamento, a VM dirá a V quais dados atualizar.