Discussão do artigo "Padrão de design MVC e a possibilidade de usá-lo"

Novo comentário
 

Novo artigo Padrão de design MVC e a possibilidade de usá-lo foi publicado:

Este artigo falará sobre um padrão MVC comum, bem como sobre os prós e os contras de seu uso em programas MQL. Seu propósito é o de "dividir" o código existente em três componentes separados: Modelo (Model), Visualização (View) e Controlador (Controller).

Neste artigo, iremos focar no "MVC clássico", sem complicações e funcionalidades adicionais. Seu propósito é o de "dividir" o código existente em três componentes separados: Modelo (Model), Visualização (View) e Controlador (Controller). A essência do padrão MVC é que esses três componentes podem ser desenvolvidos e mantidos independentemente um do outro. Um grupo separado de desenvolvedores pode trabalhar em cada componente, iniciar novas versões, corrigir bugs. É bastante óbvio que, neste caso, torna-se muito mais fácil trabalhar num projeto comum, sendo que pode ser mais rápido e fácil entender o projeto de outra pessoa.

Vamos dar uma olhada no que cada componente é individualmente.

  1. Visualização (View). A Visualização é responsável pela parte visual. De forma mais geral, ele envia dados ao usuário. Reparemos que, na realidade, pode haver várias maneiras de apresentar dados ao usuário. Por exemplo, os dados podem ser representados por uma tabela, gráfico ou diagrama ao mesmo tempo. Em outras palavras, pode haver várias Visualizações num único aplicativo construído com base no esquema MVC. As Visualizações recebem dados do modelo sem ter nenhuma ideia do que está acontecendo dentro do Modelo.
  2. Modelo (Model). O Modelo contém dados. Ele estabelece comunicação com bases de dados, envia consulta para a rede, para outras fontes. Ele modifica os dados, valida-os, armazena-os e exclui-os. O Modelo não sabe nada sobre como funciona a Visualização e quantas estão disponíveis, mas possui as interfaces necessárias através das quais elas podem solicitar dados. As Visualizações não podem fazer mais nada - elas não podem forçar o Modelo a mudar seu estado. Isso é feito pelo Controlador. Internamente, um Modelo pode ser composto por vários outros, organizados numa hierarquia ou funcionando igualmente. Nesse sentido, nenhuma restrição é imposta ao Módulo, exceto as já mencionadas - o Modelo mantém sua estrutura interna secreta da Visualização e do Controlador.
  3. Controlador (Controller). O Controlador estabelece a comunicação entre o usuário e o Modelo. O Controlador não sabe o que o Modelo está fazendo com os dados, mas pode dizer a este que é hora de atualizar o conteúdo. Em geral, o Controlador, por sua interface, trabalha com o Modelo, sem tentar entender o que está acontecendo dentro dele.

Visualmente, a relação entre os componentes individuais do padrão MVC é algo assim:

Autor: Andrei Novichkov

 

Artigo bem escrito, muito fácil de ler, obrigado!

Acho que esse modelo é ideal para um testador - é fácil alterar a lógica do EA e adicionar novas funcionalidades a ele

Sobre MVC - como você propõe tratar os erros? Por exemplo, erros ao fechar/abrir ordens para negociação real.

 

O modelo é bom porque é muito simples e claro. E ele realmente facilita a vida, como pude comprovar em primeira mão. Em geral, toda a ferramenta pode ser dividida em blocos separados, e dividida de forma razoável e lógica. Você pode obter reutilização de código, depuração, correção de erros e suporte a versões.

Eu não pensei em tratamento de erros quando estava escrevendo, obrigado. E, em essência, acho que eles devem ser tratados no componente em que ocorreram. Ou seja, se a configuração da ordem for referenciada à visualização, ela deverá ser tratada lá. Mas também há um problema se você fizer isso de forma assíncrona. Os manipuladores de eventos no Controller acabam ficando um pouco apertados.

Obrigado por sua opinião)

 
Andrei Novichkov:

Basicamente, acho que eles devem ser tratados no componente em que foram originados.

Todos fazem isso, é lógico, mas o problema é o que fazer se ocorrer um erro e for necessário que a execução posterior do código (que está abaixo) não seja executada (abortar ou reverter).

 
Você está descrevendo uma exceção)
 
Andrei Novichkov:
Você está descrevendo uma exceção).

Que exceções? - elas não existem no MQL, e talvez um dos desenvolvedores tenha escrito que esse é um estilo ruim de escrever programas, que não é necessário... bem, isso não é exato! ))))


SZY: Na minha opinião, para um testador, você deve escrever em MVC, e para valer, deve mover uma parte do código com seções críticas para OnTimer() e ... e, novamente, em vez de um código simples e legível usando modelos de programação comuns (métodos), obteremos..... provavelmente um programa no estilo MQL ))))

 

O exemplo não é muito bom; na verdade, a visualização está fora do EA.

Para exagerar, você não deve manter a lógica do modelo nas funções comerciais. Se um erro afetar a lógica, a função lançará um evento, o controlador o processará e o modelo decidirá o que fazer em seguida.

 
O MVC não é um modelo rígido e permite desvios. É claro que existem "campeões da pureza", mas isso deve ser tratado como um fenômeno da natureza
 

Em princípio, é terrível. Eles anunciaram um padrão útil, mas mostraram como não fazê-lo: afinal, MVC é OOP, e aqui, sob o pretexto de uma suposta simplificação de código, temos alguns labirintos. Pelo menos eles poderiam ter jogado o init (também conhecido como controlador) no modelo e na visualização:

int OnInit()
{
   init.Initialize(smb);
   view.Initialize(&init);
   // model.Initialize(&init);
  
   return INIT_SUCCEEDED;
}
Como um objeto global pode ser usado dentro da classe de outra pessoa, no arquivo de cabeçalho de outra pessoa?
 
Stanislav Korotky:

Em princípio, é terrível. Eles anunciaram um padrão útil, mas mostraram como não fazê-lo: afinal, MVC é OOP, e aqui, sob o pretexto de uma suposta simplificação de código, temos alguns labirintos. Pelo menos eles lançaram o init (também conhecido como controlador) no modelo e na visualização:

Como você pode usar um objeto global dentro da classe de outra pessoa, no arquivo de cabeçalho de outra pessoa?

Você leu até o fim? Eu escrevi no final sobre a comunicação entre os componentes. E também sobre o acesso a objetos globais. Nesse caso, considero o método apresentado aceitável, apenas para o entendimento da maioria. E a forma como você sugere implica o mesmo acesso descontrolado a objetos globais, só que de lado.

 

Acontece que é muito mais complicado - MVC , MVP , MVVM hubr: https: //habr.com/ru/post/215605/

Se você acredita no hubr, o autor está certo: no MVC, um modelo não deve conhecer (depender de) nada além de suas tarefas.

1234
Novo comentário