Discussion of article "MVC design pattern and its possible application"

New comment
 

New article MVC design pattern and its possible application has been published:

The article discusses a popular MVC pattern, as well as the possibilities, pros and cons of its usage in MQL programs. The idea is to split an existing code into three separate components: Model, View and Controller.

In this article we will consider the "classical MVC", without any complications or additional functionality. The idea is to split an existing code into three separate components: Model, View and Controller. According to the MVC pattern, these three components can be developed and maintained independently. Each component can be developed by a separate group of developers, who undertake to create new versions and to fix errors. Obviously this can make management of the overall project much easier. Furthermore, it can assist other people in understanding the code.

Let us take a look at each component.

  1. View. View is responsible for visual representation of information. In a general case it sends data to the user. There can be different methods for presenting the same data to the user. For example, data can be represented by a table, graph or chart at the same time. In other words, an MVC-based application can contain multiple views. Views receive data from the Model without knowing what is happening inside the Model.
  2. Model. The model contains data. It manages connections with data bases, sends requests and communicates with different resources. It modifies the data, verifies it, stores and deletes if necessary. The Model does not know anything about how the View works and how many Views exist, but it has the necessary interfaces through which the Views can request data. There is nothing else the Views can do, i.e. they cannot force the Model to change its state. This part is performed by the Controller. Internally, a Model can be composed of several other Models arranged in a hierarchy or working equally. The Model is not limited in this respect, except for the previously mentioned restriction — the Model keeps its internal structure in secret from the View and the Controller.
  3. Controller. The Controller implements communication between the user and the Model. The Controller does not know what the Model is doing with the data, but it can tell the Model that it is time to update the content. In general, the Controller works with the Model by its interface, without trying to understand what is happening inside it.

The relationship between the individual components of the MVC pattern can be visually represented as follows:


Author: Andrei Novichkov

 

well written article material, very easy to read, thanks!

I think this template is ideal for a tester - it is easy to change EA logic and add new functionality to it

on MVC - how do you propose to handle errors? e.g. errors when closing/opening orders for real trading.

 

The template is good because it is very simple and clear. And it really makes life easier, I experienced it first-hand. In general, the whole tool can be broken down into separate bricks, and broken down reasonably, logically. You can get code reuse, debugging, error fixing and version support.

I didn't think about error handling when I was writing, thank you. And in essence, I think they should be handled in the component where they occurred. That is, if order setting is referred to the View, then it should be handled there. But there is also a problem if you do it asynchronously. Event handlers in the Controller, it turns out to be a bit cramped.

Thanks for your kind opinion )

 
Andrei Novichkov:

And essentially, I think they should be handled in the component where they originated.

everyone does that, it's logical - but the problem is what to do if an error occurs and further execution of the code (which is below) is required not to execute (abort/ or rollback), I thought maybe your article will highlight this point.

 
You are describing an exception )
 
Andrei Novichkov:
You're describing an exception.)

What exceptions!? - they don't exist in MQL, and maybe one of the developers wrote that it's a bad style of writing programmes, it's not necessary... well, it's not accurate! ))))


SZY: imho, for a tester you should write in MVC, for real you should move a part of code with critical sections to OnTimer() and ... and again instead of a simple readable code using common programming templates (methods) we will get..... probably an MQL-styled programme ))))

 

The example is just not very good, in fact view is outside the EA.

To exaggerate - you should not keep the logic of the model in trade functions. If an error affects the logic - the function throws an event, the controller processes it, the model decides what to do next.

 
MVC is not a rigid template and allows deviations. There are, of course, "champions of purity", but this should be treated as a phenomenon of nature
 

In principle, it's terrible. They announced a useful pattern, but showed how not to do it: after all, MVC is OOP, and here, under the pretext of supposed code simplification, we got some mazes. At least they could have thrown init (aka controller) into the model and view:

int OnInit()
{
   init.Initialize(smb);
   view.Initialize(&init);
   // model.Initialize(&init);
  
   return INIT_SUCCEEDED;
}
How can a global object be used inside someone else's class, in someone else's header file?!
 
Stanislav Korotky:

In principle, it's terrible. They announced a useful pattern, but showed how not to do it: after all, MVC is OOP, and here, under the pretext of supposed code simplification, we got some mazes. At least they have thrown init (aka controller) into the model and view:

How can you use a global object inside someone else's class, in someone else's header file?!

Have you read to the end? I wrote at the end about communication between components. And about access to global objects too. In this case, I consider the presented method acceptable, just for the understanding of the majority. And the way you suggest implies the same uncontrolled access to global objects, only from the side.

 

it turns out to be much more complicated - MVC , MVP , MVVM hubr: https: //habr.com/ru/post/215605/

If you believe the hubr, the author has it right, in MVC a model should not know (depend on) anything except its tasks.

1234
New comment