Estive lendo sobre o Model View Controller, o Model View Presenter, o Model View ViewModel, e assim por diante, e geralmente, o conceito subjacente parece bastante simples de entender: mantenha os visuais bonitos e as entranhas científicas tão separados e ignorantes um do outro quanto possível. Não é possível obter a lógica da manteiga de amendoim no chocolate de design; legal, eu gosto disso.
O problema é que ainda estou um pouco confusa quanto à terceira parte ... a que não é modelo ou visão. Todo mundo parece ter sua própria idéia de como chamá-lo, o que deve fazer, o que é adequado, o que está errado ... e estou ficando louco tentando descobrir quando um Apresentador se torna um ViewModel e quando um View não deve ' Não faça isso porque esse é o trabalho do apresentador e--
Estou divagando.
Em vez de pedir a alguém para explicar a diferença entre eles - porque isso já foi feito inúmeras vezes (eu sei; li mais artigos do que posso contar) - ficaria curioso em ouvir os pensamentos de um alguns programadores do modelo que eu mesmo fiz.
Dito isto, como você classificaria esse design como, e talvez mais importante, você vê algo sobre isso que obviamente é péssimo? Claro, eu adoraria ouvir que estou indo bem se esse design realmente for sólido, mas prefiro receber conselhos sólidos sobre elogios.
Nota: Eu vou usar "the Bridge" para a misteriosa terceira parte do Model-View-? para evitar sugestões subconscientes do que "deveria" ser.
Modelo
- É a autoridade em dados.
- Recebe informações sobre as mudanças solicitadas do Bridge.
- Contém e executa toda a lógica de como os dados se relacionam com outros dados.
Informa o Bridge quando os dados são alterados (para dados nos quais o Bridge manifestou interesse).Edição de texto: permite que assinantes externos (sobre os quais nada sabe) monitorem seus resultados de estado ou cálculo.- Não tem conhecimento da vista.
Visão
- Está preocupado em fornecer ao usuário uma maneira de visualizar e manipular dados.
- Recebe informações sobre atualizações de dados do Bridge.
- Contém e executa toda a lógica de como apresentar dados e controles ao usuário.
- Informa o Bridge quando o usuário executou uma ação que (possivelmente) afeta o modelo.
- Informa ao Bridge quais informações estão interessadas.
- Não tem conhecimento do modelo.
Ponte
- É o coordenador e tradutor entre o modelo e a visualização.
- Faz as alterações de formatação apropriadas nas informações passadas entre o Modelo e a Visualização.
- Mantém informações sobre "quem precisa saber o que".
- Possui conhecimento do modelo e da visualização.
Notas Adicionais
- Em programas mais complicados, é comum haver vários modelos. Nessa situação, o Bridge normalmente assume o trabalho de coordenar / traduzir entre os vários modelos e, portanto, se torna a autoridade sobre a qual modelos protocall / API / design devem ser construídos. (por exemplo, se você estiver construindo um programa de jogo de cartas e quiser criar um modelo de baralhamento alternado, use o Bridge para determinar quais funções são necessárias para a comunicação adequada com o Bridge.)
- Em pequenos programas simples com apenas uma Visualização e Modelo, é comum o Bridge "assumir" que funcionalidade está disponível em ambos os lados. No entanto, à medida que os programas se tornam mais complexos, é recomendável que a (s) Visualização (ões) e Modelo (s) reportem sua funcionalidade ao Bridge, para evitar ineficiências e suposições de bugs.
Eu acho que isso cobre tudo. Por todos os meios, dou boas-vindas a todas as perguntas que você possa ter sobre o design que costumo usar e também encorajo quaisquer sugestões.
E como sempre, obrigado pelo seu tempo.