Discussão do artigo "Padrão de design MVC e a possibilidade de usá-lo" - página 2
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Acontece que é muito mais complicado do que isso - MVC , MVP , MVVM hub: 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, exceto de suas tarefas.
Bem, é claro que eu tenho tudo corretamente declarado )))). Mas o MVC não é muito exigente em termos de disciplina, o que me agrada particularmente
O MQL é "bem qualificado" no trabalho com estruturas (construtor de cópia, trabalho com arquivos, trabalho com SQLite).
É realista usar o modelo MVC de modo que a interação seja organizada por meio de algumas estruturas de estado/parâmetro, ou seja, passar essas estruturas por referência. Ou precisamos de outro modelo?
É muito real. É um bom caminho. Uma observação nesse sentido foi feita acima. Mas é melhor trocar referências não para algumas estruturas, mas para os próprios componentes. Por exemplo, uma visualização pode precisar de acesso a um modelo. E o modelo pode fornecer métodos para acessar determinados objetos/estruturas ou submodelos maiores. Lembre-se de que a visualização não deve alterar o modelo. Portanto, o acesso deve ser apropriado.
É muito real. É um bom caminho. O comentário acima foi feito exatamente nesse sentido.
É necessário um exemplo
ou um artigo melhor.... apenas e o tratamento de erros do servidor pode ser feito
exemplo
ou, melhor ainda, um artigo.... você pode fazer exatamente isso e o tratamento de erros do servidor
Bem, em princípio, você pode) Fazer a segunda parte não em um nível primitivo, mas em um nível real e funcional. Vou pensar sobre isso. Não quero criar artigos no mesmo lugar, eles vão rir.
Faça a segunda parte não em um nível primitivo, mas em um nível real e funcional.
Acho que isso seria prático para todos.
E para não inflar o artigo em cento e cinquenta seções sobre tratamento de erros, acho que é suficiente tratar de 1 a 2 erros de servidor (envio/fechamento de ordens) e 1 a 2 erros de terminal(obtenção de preços atuais/timesframes?....).
Bem, e usar estruturas o máximo possível é relevante para mim, suspeito que tanto os erros quanto salvar o estado do EA podem ser organizados de forma eficiente em um arquivo binário usando estruturas.
Você leu até o final? Eu escrevi no final sobre a comunicação entre os componentes. E também sobre o acesso a objetos globais. Nesse caso, considero a forma apresentada aceitável, apenas para o entendimento da maioria. E a forma que você sugeriu implica o mesmo acesso descontrolado a objetos globais, só que de lado.
Aparentemente, você não percebeu que eu já me referi às suas desculpas no artigo em meu comentário.
Você ensina a maioria das pessoas como não fazer as coisas, não o MVC ou a OOP. E a frase destacada em verde apenas reflete seu entendimento errado de como ela deve ser implementada.
Aparentemente, você não percebeu que era às suas desculpas no artigo que eu já estava me referindo em meu comentário.
Você ensina à maioria como não fazer as coisas, não o MVC ou a OOP. E a frase destacada em verde apenas reflete seu entendimento errado de como ela deve ser implementada.
Tem certeza de que é isso que vale a pena discutir nos comentários do artigo?
Fico impressionado com o quanto nosso fórum gosta desse tipo de expressão/conselho )))). A propósito, eu servi naquelas regiões, era meio dia de caminhada até a China).
Tem certeza de que é isso que vale a pena discutir nos comentários do artigo?
Por que não? Tome nota e corrija isso no próximo artigo.