Обсуждение статьи "Шаблон проектирования MVC и возможность его использования"
хорошо написан материал статьи, очень легко читается, спасибо!
для тестера этот шаблон, имхо, идеален - легко изменять логику ЕА, дополнять новым функционалом
по MVC - как предлагаете обрабатывать ошибки? например ошибки при закрытии/открытии ордеров для реальной торговли
Шаблон хорош тем, что он очень прост и понятен. И он реально облегчает жизнь, я это на собственном опыте испытал. Вообще весь инструмент можно разбить на отдельные кирпичики, причем обоснованно разбить, логично. И повторное использование кода получить, и отладку, фиксацию ошибок, поддержку версий.
Про обработку ошибок я не додумал, когда писал, спасибо. А по существу, думаю, их надо обрабатывать в том компоненте, где они возникли. Т.е. если установку ордеров относить к Представлению, то там и обрабатывать. Но и проблема тоже имеется, если асинхронно это делать. Обработчики событий в Контроллере, несколько корявенько получается.
Спасибо за доброе мнение )
А по существу, думаю, их надо обрабатывать в том компоненте, где они возникли.
все так и делают, это логично - но проблема, что делать если возникла ошибка и дальнейшее выполнение кода (который ниже) требуется не выполнять (прервать/ или откатиться), думал может Ваша статья осветит этот момент
Вы описываете исключение )
какие такие исключения!? - их нет в MQL, и возможно, кто то из разработчиков писал, что это плохой стиль написания программ, это не нужно... ну в общем, это не точно! ))))
ЗЫ: имхо, для тестера писать по MVC, для реала переносить часть кода с критическими секциями в OnTimer() и ... и опять вместо простого читаемого кода по общепринятым шаблонам (методикам) программирования получим.... наверно MQL-стайл программу )))
Да пример просто не очень, по сути view находится за пределами советника.
Если утрировать - не стоит в торговых функциях держать логику модели. Если ошибка затрагивает логику - функция кидает событие, контроллер его обрабатывает, модель решает что делать дальше.
В принципе, ужос. Вроде анонсировали полезный паттерн, но показали как не надо делать: все-таки MVC - это ООП, а тут под предлогом мнимого упрощения кода получились какие-то дебри. Хотя бы прокинули init (он же контроллер) в модель и представление:
int OnInit() { init.Initialize(smb); view.Initialize(&init); // model.Initialize(&init); return INIT_SUCCEEDED; }Как можно глобальный объект использовать внутри чужого класса, в чужом заголовочном файле?!
В принципе, ужос. Вроде анонсировали полезный паттерн, но показали как не надо делать: все-таки MVC - это ООП, а тут под предлогом мнимого упрощения кода получились какие-то дебри. Хотя бы прокинули init (он же контроллер) в модель и представление:
Как можно глобальный объект использовать внутри чужого класса, в чужом заголовочном файле?!Вы до конца дочитали? Я же пишу в конце о коммуникациях между компонентами. И о доступе к глобальным объектам тоже. В данном случае я считаю представленный способ допустимым, именно для понимания большинства. А тот способ, который предлагаете Вы, подразумевает такой же неконтролируемый доступ к глобальным объектам, только вид сбоку.
оказывается все намного сложнее - MVC , MVP , MVVM хабр: https://habr.com/ru/post/215605/
если верить хабру, то у автора все правильно изложено, в MVC модель не должна ничего знать (зависеть) кроме своих задач
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Шаблон проектирования MVC и возможность его использования:
В статье рассматривается распространенный шаблон MVC, возможность, плюсы и минусы его применения в программах на MQL. Его суть в том, чтобы "разделить" имеющийся код на три отдельных компонента: Модель (Model), Представление (View) и Контроллер (Controller).
Нас в этой статье будет интересовать "классический MVC", без усложнений и дополнительного функционала. Его суть в том, чтобы "разделить" имеющийся код на три отдельных компонента: Модель (Model), Представление (View) и Контроллер (Controller). Суть шаблона MVC в том, что эти три компонента могут разрабатываться и сопровождаться независимо друг от друга. Над каждым компонентом может работать отдельная группа разработчиков, выпускать новые версии, устранять ошибки. Вполне очевидно, что в таком случае становится значительно легче работа над общим проектом, и в чужом разобраться бывает быстрее и проще.
Рассмотрим, что представляет собой каждый компонент по отдельности.
Визуально, связь между отдельными компонентами шаблона MVC выглядит примерно так:
Автор: Andrei Novichkov