MVC para aplicativo de desktop sem camada de dados

Question

A pergunta pode ser complicada (devido à sua natureza ou à minha maneira de descrevê-la), então leia isto antes de responder.

Eu tenho este aplicativo para escrever:
a) aplicativo de desktop;
b) nenhuma camada de dados no sentido de banco de dados, arquivos ou qualquer outro repositório (não há necessidade de salvar, armazenar ou carregar dados);
c) o aplicativo terá alguns algoritmos de computação implementados (Algoritmo Genético);
b) fornece GUI que exibirá controles para aplicativos e resultados de cálculos.

Estou pensando em usar o padrão MVC mas tenho dúvidas de como utilizá-lo.Como não tenho nenhuma camada de dados no sentido (por exemplo) de banco de dados (os dados são gerados durante a execução com base na entrada do usuário), estou preocupado com a maneira de usar o MVC nesta implementação.Até agora, criei duas abordagens:

1. GUI é a visualização.GeneticAlgorithm é o controlador.GeneticAlgorithmResults é o Modelo (como classe que armazena apenas dados).Fluxo básico:

   • A View envia a entrada do usuário para o Controller;
   • O Controlador processa a entrada do usuário e gera dados;
   • O Controlador envia os dados gerados para o Modelo;
   • O Modelo notifica a Visualização sobre novos dados;
   • A Visualização extrai novos dados e atualiza a exibição.

2. GUI é a visualização.AppEngine é o controlador.GeneticAlgorithm e GeneticAlgorithmResults são o modelo.Agora temos:

   • A View envia a entrada do usuário para o Controller;
   • O Controlador está processando a entrada do usuário e envia sinais de controle para o Modelo.
   • O Modelo atualiza seu estado interno (gera novos dados);
   • O Modelo notifica o Controlador sobre novos dados;
   • O Controlador extrai dados para modelar;
   • O Controlador processa dados;
   • O controlador envia os dados processados ​​para a Visualização;
   • A Visualização atualiza a exibição.

A primeira abordagem parece ser mais direta e mais parecida com MVC.O problema é que alguma lógica teria que estar no modelo - decidir quando notificar o modelo, pois nem todas as atualizações de dados serão exibidas, ou talvez a exibição seja atualizada com os conjuntos de dados e não com cada pequena alteração.Essas decisões serão baseadas nas informações do usuário.Além disso, pode ser necessário algum processamento adicional dos dados antes da exibição real.Isso estaria na Visualização.

Por outro lado, a segunda abordagem parece ser mais complicada e parece que muitas mensagens estão sendo passadas para realizar a tarefa.Mas dá controle total da Lógica ao Controlador e separa as responsabilidades da Visualização, do Controlador e do Modelo (que é o objetivo principal do MVC).

Qual abordagem você recomendaria?Ou talvez eu deva misturá-los e usar a arquitetura de primeira abordagem com o fluxo de comunicação da segunda abordagem?Ou algum design diferente?

Answer 1

Do meu entendimento do MVC, a segunda versão é mais parecida com o paradigma estrito do MVC.No entanto, um dos meus professores muito inteligentes uma vez me disse que os padrões de design existem para fornecer um conjunto vago de diretrizes e não são necessariamente feitos para serem seguidos à risca.

Na minha opinião, uma mistura de ambos é uma boa ideia.Se alguma lógica acabar no Modelo, não é o fim do mundo, significa apenas que você precisa ter mais cuidado ao acompanhar a separação de seus componentes.Se uma pequena modificação no MVC tornar sua vida 50% mais fácil (menos sobrecarga de mensagens), provavelmente será uma boa ideia.

Answer 2

Eu definitivamente escolheria algo mais próximo da segunda implementação.Sim, parece que mais mensagens são passadas de um lado para o outro, mas se seu aplicativo crescer e mudar, você ficará feliz por ter criado o aplicativo com classes pequenas.

Considerar:Onde está a lógica para lidar com tarefas mundanas, como alternar entre algoritmos, executá-los e processar os dados para visualização?

Algoritmos genéticos operam com algum tipo de entrada ou dados iniciais, não é?Você obteria isso da sua camada de acesso a dados.Você não precisa de dados iniciais ou condições de inicialização?Que tal salvar seus resultados em um arquivo e recuperá-los para revisão posterior?Eu acho que você precisa fazer isso quando seu aplicativo amadurecer.Espere que a princípio você use persistência baseada em arquivo.Se você estiver com vontade, mais tarde poderá atualizar para um banco de dados.Se você codificar em uma camada de persistência de dados abstraídos, não precisará alterar a lógica de negócios posteriormente para dar suporte à mudança do arquivo para o banco de dados.

Você deve usar o padrão de estratégia para implementar seus algoritmos.Isso permitirá que você altere a implementação do seu solucionador de algoritmo genético para outros algoritmos sem precisar alterar a lógica de negócios de cada algoritmo.

A camada de negócios verá um ISolver que recebe entradas e você chamará mySolver.Solve().Você deve poder alternar entre as diferentes versões sem precisar alterar a lógica da camada de negócios (Princípio Aberto Fechado).A única diferença na forma como a lógica de negócios deve interagir com os algoritmos deve estar no construtor e, mesmo assim, você deve considerar o uso de um padrão Factory.