Discussion of article "MVC design pattern and its possible application" - page 3

New comment
 
Maxim Kuznetsov:

Why not? Take note, fix it in the next one.

That's not what he means. Not a correction, but compared my level and my opponent's level.

 

I find this article very interesting and useful for those who are unfamiliar with this topic.

I would like to express my gratitude to the author for good presentation and ease of reading.

And as Andrey mentioned in the article, it is not so easy to make an ideal MVC indicator programme. But I liked the examples in the article very much.

 
Rashid Umarov:

I find this article very interesting and useful for those who are unfamiliar with this topic.

I would like to express my gratitude to the author for good presentation and ease of reading.

And as Andrey mentioned in the article, it is not so easy to make an ideal MVC indicator programme. But I liked the examples in the article very much.

Thank you for your flattering opinion, Rashid )

 

@Andrei Novichkov, to which component should logging be attributed? To the View? But it's kind of boring to transfer every log line from Model to View via Controller.

Andrei Novichkov
Andrei Novichkov
  • 2021.03.24
  • www.mql5.com
Профиль трейдера
 
Logging can be made as another representation. The Model knows about the View and can communicate with it bypassing the Controller. And note that logging can take place not only in the Model, but also in the View.
 

@Andrei Novichkov, I see, thank you.

One more question: how correct is it to define input parameters only in the Controller? Isn't it more correct to define such input parameters as iSlippage and Magic in the View (because the Controller doesn't need them)? Then after including the file with the View into the file with the Controller, these parameters will appear as one group in the input settings of the Expert Advisor.

Andrei Novichkov
Andrei Novichkov
  • 2021.03.24
  • www.mql5.com
Профиль трейдера
 
Why make two entities instead of a logically complete entity. Or three. Or four. The right thing to do is to make one entity and think about a controlled way of access for Model and Representation.
 
Andrei Novichkov:
Why make two entities instead of a logically complete entity. Or three. Or four. The right thing to do is to make one entity and think of a controlled way of access for Model and Representation.

I'm not sure you understand what I'm saying. I'm not suggesting to create new entities - no. As it was three components so it will remain.

It is just that otherwise it is illogical to declare iSlippage and Magic variables at the global level of the Controller, which are not used by it, but can be used only in the View. As a result, the .mqh file of the View will not be formally pseudo-compiled by F7, which will not allow to automatically check syntax errors (I am not talking about your example, but in general, when these variables are used in the View).

 
There may be many parameters in the input parameters, among them Magik. Scatter these parameters among different components? In my opinion, this is not the best solution. But you can try your idea. See how it will look like.
 
Ok, thanks for the article and answering the questions.
1234
New comment