Обсуждение статьи "Шаблон проектирования MVC и возможность его использования" - страница 3

Новый комментарий
 
Maxim Kuznetsov:

почему нет ? примите к сведению, в следующей исправьте

Он же не это имеет в виду. Не исправление, а сравнил мой уровень и уровень оппонента.

 

Считаю данную статью очень интересной и полезной для тех, кто незнаком с данной темой.

Автору хочу выразить благодарность за хорошую подачу и легкость чтения.

И как отметил в статье Андрей, сделать идеальную с точки зрения MVC программу-индикатор не так просто. Но сами примеры в статье мне очень понравились.

 
Rashid Umarov:

Считаю данную статью очень интересной и полезной для тех, кто незнаком с данной темой.

Автору хочу выразить благодарность за хорошую подачу и легкость чтения.

И как отметил в статье Андрей, сделать идеальную с точки зрения MVC программу-индикатор не так просто. Но сами примеры в статье мне очень понравились.

Спасибо за лестное мнение, Рашид )

 

@Andrei Novichkov, а к какому компоненту следует отнести логирование? К Представлению? Но вроде занудно каждую лог-строку из Модели переправлять в Представление через Контролер.

Andrei Novichkov
Andrei Novichkov
  • 2021.03.24
  • www.mql5.com
Профиль трейдера
 
Логирование можно сделать, как еще одно Представление. Модель знает о Представлении и может с ней общаться минуя Контроллер. И обратите внимание, логирование ведь может происходить не только в Модели, но и в Представлении.
 

@Andrei Novichkov, понятно, спасибо.

Ещё вопросик: насколько правильно входные input-параметры определять только в Контролере? Не правильнее ли такие входные параметры как iSlippage и Magic определять в Представлении (ведь Контролеру они не нужны)? Тогда после включения файла с Представлением в файл с Контролером эти параметры появятся одной группой во входных настройках советника .

Andrei Novichkov
Andrei Novichkov
  • 2021.03.24
  • www.mql5.com
Профиль трейдера
 
Зачем вместо логически законченной сущности плодить две. Или три. Или четыре. Правильно сделать одну и продумать контролируемый способ доступа  для Модели и Представления.
 
Andrei Novichkov:
Зачем вместо логически законченной сущности плодить две. Или три. Или четыре. Правильно сделать одну и продумать контролируемый способ доступа  для Модели и Представления.

Не уверен, что Вы меня поняли. Я не предлагаю плодить новые сущности - нет. Как было три компонента так и останется.

Просто иначе получается нелогично объявлять на глобальном уровне Контролера переменные iSlippage и Magic, которые им не используются, а могут использоваться только в Представлении. В результате .mqh- файл Представления не будет формально псевдо-компилироваться по F7, что не даст возможности автоматически проверять синтаксические ошибки (я не про Ваш пример - а вообще, при задействовании этих переменных в Представлении).

 
Во входных параметрах может быть много параметров, среди них и Магик. Разбросать  эти параметры по разным компонентам? По моему, это далеко не лучшее решение.  Но Вы же можете попробовать свою идею. Посмотреть, как это будет выглядеть.
 
Хорошо, спасибо за статью и ответы на вопросы.
123
Новый комментарий