Diskussion zum Artikel "MVC-Entwurfsmuster und seine mögliche Anwendung"

 

Neuer Artikel MVC-Entwurfsmuster und seine mögliche Anwendung :

Der Artikel stellt ein beliebtes MVC-Muster vor sowie die Möglichkeiten, Vor- und Nachteile seiner Verwendung in MQL-Programmen. Die Idee ist, einen bestehenden Code in drei separate Komponenten aufzuteilen: Model, View (Darstellung) und Controller.

In diesem Artikel werden wir das "klassische MVC" betrachten, ohne jegliche Komplikationen oder zusätzliche Funktionalität. Die Idee ist, einen bestehenden Code in drei separate Komponenten aufzuteilen: Model, View (Darstellung) und Controller. Nach dem MVC-Muster können diese drei Komponenten unabhängig voneinander entwickelt und gewartet werden. Jede Komponente kann von einer separaten Gruppe von Entwicklern entwickelt werden, die sich um die Erstellung neuer Versionen und die Behebung von Fehlern kümmern. Dies kann natürlich die Verwaltung des Gesamtprojekts erheblich vereinfachen. Außerdem kann es anderen Personen helfen, den Code zu verstehen.

Werfen wir einen Blick auf die einzelnen Komponenten.

  1. View. View ist für die visuelle Darstellung von Informationen zuständig. In einem allgemeinen Fall sendet es Daten an den Benutzer. Es kann verschiedene Methoden geben, um dieselben Daten dem Benutzer zu präsentieren. Zum Beispiel können Daten gleichzeitig durch eine Tabelle, ein Diagramm oder ein Diagramm dargestellt werden. Mit anderen Worten: Eine MVC-basierte Anwendung kann mehrere Views enthalten. Views erhalten Daten vom Model, ohne zu wissen, was im Model passiert.
  2. Model. Das Model enthält Daten. Es verwaltet Verbindungen mit Datenbanken, sendet Anfragen und kommuniziert mit verschiedenen Ressourcen. Es verändert die Daten, prüft sie, speichert und löscht sie, wenn nötig. Model weiß nichts darüber, wie die Ansicht funktioniert und wie viele Ansichten existieren, aber es hat die notwendigen Schnittstellen, über die die Ansichten Daten anfordern können. Mehr können die Views nicht tun, d. h. sie können Model nicht zwingen, seinen Zustand zu ändern. Dieser Teil wird vom Controller übernommen. Intern kann Model aus mehreren anderen Models zusammengesetzt sein, die in einer Hierarchie angeordnet sind oder gleichberechtigt arbeiten. Das Model ist in dieser Hinsicht nicht eingeschränkt, abgesehen von der bereits erwähnten Einschränkung — das Model hält seine interne Struktur vor der View und dem Controller geheim.
  3. Controller. Controller implementiert die Kommunikation zwischen dem Nutzer und Model. Der Controller weiß nicht, was das Model mit den Daten macht, aber er kann dem Model mitteilen, dass es an der Zeit ist, den Inhalt zu aktualisieren. Im Allgemeinen arbeitet der Controller mit dem Model über dessen Schnittstelle, ohne zu versuchen zu verstehen, was in ihm vorgeht.

Die Beziehung zwischen den einzelnen Komponenten des MVC-Musters kann visuell wie folgt dargestellt werden:

Autor: Andrei Novichkov

 

gut geschriebenes Artikelmaterial, sehr leicht zu lesen, danke!

Ich denke, diese Vorlage ist ideal für einen Tester - es ist einfach, die EA-Logik zu ändern und neue Funktionen hinzuzufügen

zu MVC - wie schlagen Sie vor, mit Fehlern umzugehen? z.B. Fehler beim Schließen/Öffnen von Aufträgen für den echten Handel.

 

Die Vorlage ist gut, weil sie sehr einfach und klar ist. Und sie macht das Leben wirklich einfacher, das habe ich aus erster Hand erfahren. Im Allgemeinen kann das ganze Tool in einzelne Bausteine zerlegt werden, und zwar auf vernünftige, logische Weise. Man kann Code wiederverwenden, debuggen, Fehler beheben und Versionsunterstützung erhalten.

Ich habe beim Schreiben nicht an die Fehlerbehandlung gedacht, vielen Dank. Und ich denke, dass sie im Wesentlichen in der Komponente behandelt werden sollten, in der sie aufgetreten sind. Das heißt, wenn sich die Einstellung der Reihenfolge auf die Ansicht bezieht, dann sollte sie dort behandelt werden. Aber es gibt auch ein Problem, wenn man es asynchron macht. Event-Handler im Controller, dann wird es ein bisschen eng.

Vielen Dank für Ihre Meinung )

 
Andrei Novichkov:

Ich bin der Meinung, dass sie in der Komponente behandelt werden sollten, aus der sie stammen.

Jeder tut das, es ist logisch - aber das Problem ist, was zu tun ist, wenn ein Fehler auftritt und die weitere Ausführung des Codes (die unten ist) erforderlich ist, nicht auszuführen (Abbruch / oder Rollback), ich dachte, vielleicht Ihr Artikel wird diesen Punkt zu beleuchten.

 
Sie beschreiben eine Ausnahme )
 
Andrei Novichkov:
Du beschreibst eine Ausnahme.)

Welche Ausnahmen!? - die gibt es in MQL nicht, und vielleicht hat einer der Entwickler geschrieben, dass es ein schlechter Stil ist, Programme zu schreiben, es ist nicht notwendig... Nun, das ist nicht korrekt! ))))


SZY: imho, für einen Tester sollte man in MVC schreiben, in Wirklichkeit sollte man einen Teil des Codes mit kritischen Abschnitten nach OnTimer() und ... und anstelle eines einfach lesbaren Codes mit gängigen Programmiervorlagen (Methoden) erhalten wir wieder..... wahrscheinlich ein Programm im MQL-Stil ))))

 

Das Beispiel ist einfach nicht sehr gut, in der Tat Ansicht ist außerhalb der EA.

Um es zu übertreiben - Sie sollten die Logik des Modells nicht in Handelsfunktionen halten. Wenn ein Fehler die Logik betrifft - die Funktion wirft ein Ereignis, der Controller verarbeitet es, das Modell entscheidet, was als nächstes zu tun.

 
MVC ist keine starre Vorlage und lässt Abweichungen zu. Natürlich gibt es "Reinheitsverfechter", aber das sollte als Naturphänomen behandelt werden
 

Im Prinzip ist es schrecklich. Sie haben ein nützliches Muster angekündigt, aber gezeigt, wie man es nicht macht: MVC ist schließlich OOP, und hier haben wir unter dem Vorwand der angeblichen Codevereinfachung einige Labyrinthe. Zumindest hätten sie init (aka Controller) in das Model und die View einbauen können:

int OnInit()
{
   init.Initialize(smb);
   view.Initialize(&init);
   // model.Initialize(&init);
  
   return INIT_SUCCEEDED;
}
Wie kann ein globales Objekt in einer fremden Klasse, in einer fremden Header-Datei verwendet werden?!
 
Stanislav Korotky:

Im Prinzip ist es schrecklich. Sie haben ein nützliches Muster angekündigt, aber gezeigt, wie man es nicht macht: MVC ist schließlich OOP, und hier haben wir unter dem Vorwand der angeblichen Code-Vereinfachung einige Labyrinthe. Wenigstens haben sie init (aka Controller) in das Model und die View geworfen:

Wie kann man ein globales Objekt in einer fremden Klasse, in einer fremden Header-Datei verwenden?!

Haben Sie bis zum Ende gelesen? Ich habe am Ende über die Kommunikation zwischen Komponenten geschrieben. Und auch über den Zugriff auf globale Objekte. In diesem Fall halte ich die vorgestellte Methode für akzeptabel, nur zum Verständnis der Mehrheit. Und der Weg, den Sie vorschlagen, impliziert den gleichen unkontrollierten Zugriff auf globale Objekte, nur von der Seite.

 

es stellt sich heraus, dass es viel komplizierter ist - MVC , MVP , MVVM hub: https: //habr.com/ru/post/215605/

Wenn man dem Hubr glaubt, hat der Autor recht, in MVC sollte ein Modell nichts außer seinen Aufgaben kennen (davon abhängen).