Diskussion zum Artikel "Integration von MQL-basierten Expert Advisors und Datenbanken (SQL Server, .NET und C#)"
Der Artikel Integration von MQL Expert Advisor und Datenbanken (SQL Server, .NET und C#) wurde veröffentlicht:
Autor: Sergey Tkachenko
Danke für den Artikel, erst kürzlich haben wir im Forum diskutiert, wie man C# DLL direkt mit MQL5 verbinden kann. Davor habe ich eine C++ DLL verwendet. Sergey, kann Entity Framework mit dieser Technologie verwendet werden? Besonders CodeFirst ist von Interesse.
Leider kann ich nichts über Entity Framework sagen - ich habe noch nie damit gearbeitet. Und ich habe wenig Erfahrung mit den relativ neuen Technologien C# und .NET.
Wenn ich es tun müsste, würde ich es versuchen. Vermutlich wird es funktionieren. Vor allem, wenn man erweiterte Funktionen nicht in exportierten statischen Funktionen verwendet, sondern sie in private Funktionen einiger Hilfsklassen verpackt und dort anwendet. In einem meiner Projekte habe ich Klassen aus System.Collections.Generic.
Leider kann ich nichts über Entity Framework sagen - ich habe noch nie damit gearbeitet. Und ich habe wenig Erfahrung mit den relativ neuen C#- und .NET-Technologien im Allgemeinen.
Wenn ich es tun müsste, würde ich es versuchen. Vermutlich wird es funktionieren. Vor allem, wenn man erweiterte Funktionen nicht in exportierten statischen Funktionen verwendet, sondern sie in private Funktionen einiger Hilfsklassen verpackt und dort anwendet. Ich habe in einem meiner Projekte Klassen aus System.Collections.Generic verwendet.
Ich sehe, ich habe Erfahrung, ich werde es ausprobieren, wenn ich die Gelegenheit habe. Haben Sie im Allgemeinen irgendwelche Nachteile beim Exportieren von Funktionen aus .NET DLL-Dateien in nicht verwalteten Code festgestellt? Ich meine, dass Renat F. viel über solche Dinge schwört. Er gibt die allgemeinsten Argumente auf der Ebene von Gruselgeschichten an.
Haben Sie die Nachteile bemerkt? Zum Beispiel verringerte Leistung, erhöhter Speicherverbrauch, usw.
Wir können nur über die Nachteile im Vergleich zu etwas anderem sprechen.
Wenn wir EAs, die den Export von Funktionen aus der DLL verwenden, mit EAs vergleichen, die das nicht tun und mit reiner MQL arbeiten - dann hängt alles von der Implementierung eines bestimmten EAs ab und davon, welche Aufgaben er erfüllt. Wenn es zwei EAs gibt, die genau das Gleiche tun, dann ist es schwer zu sagen. Ich gehe davon aus, dass derjenige, der eine DLL verwendet, aufgrund der besseren Code-Optimierung durch Compiler bei der Erstellung von DLLs schneller sein wird. Aber das ist nur eine Vermutung, denn ich habe keinen direkten Vergleich angestellt. In der Regel habe ich in DLL nur das gemacht, was in MQL schwieriger oder unmöglich ist (zum Beispiel die Arbeit mit der im Artikel beschriebenen Datenbank). Daher haben meine Expert Advisors mit und ohne DLL-Zugang unterschiedliche Aufgaben erfüllt.
Expert Advisors, die DLLs verwenden, haben einen Nachteil - weniger Zuverlässigkeit. Manchmal, wenn auch selten, erhalten sie die Fehlermeldung "Access violation at 0x08364576" (Speicheradressziffern sind unterschiedlich). Bei Robotern, die auf reiner MQL basieren, treten solche Fehler nicht auf. Natürlich hängt alles von einer bestimmten DLL ab - wie sie implementiert ist, wie komplex sie ist, ob alle potenziell gefährlichen Stellen in Bezug auf Speicherfehler überprüft wurden. Aber bei meinen Expert Advisors kommt es vor, dass zwei oder drei Monate lang alles gut funktioniert und dann beim Neustart einer der fünf Expert Advisors, die auf einem MT laufen, diesen Fehler im Log hat. Im Falle von reinem MQL passiert das nicht.
Wenn wir den Export von Funktionen aus DLLs in C# mit dem Export aus regulären DLLs - z. B. in C++ - vergleichen, dann hat jeder Ansatz seine eigenen Vor- und Nachteile. Ich habe eine andere DLL in C++ und Qt erstellt. Sie funktionierte auch mit einer Datenbank, aber mit SQLite, nicht mit SQL Server. Es gab auch Speicherzugriffsfehler, und zwar viel häufiger als bei der .NET-DLL. Aber wenn das Projekt "aufgeräumt" wird, wenn überall, wo es nötig ist, Zeiger auf Null überprüft werden, Speicher freigegeben wird und so weiter - dann ist das Gegenteil vielleicht zuverlässiger. Aber in C# ist es irgendwie einfacher, da wird alles automatisch geprüft und freigegeben. Ich habe keine Unterschiede in der Leistung festgestellt. Allerdings wurde mein C++/Qt-Projekt auch nicht sehr stark ausgenutzt.
Über die Nachteile kann man nur im Vergleich zu allem anderen reden.
Wenn wir EAs, die den Export von Funktionen aus der DLL verwenden, mit EAs vergleichen, die das nicht tun und mit reiner MQL arbeiten - dann hängt alles von der Implementierung eines bestimmten EAs ab und davon, welche Aufgaben er ausführt. Wenn es zwei EAs gibt, die genau dasselbe tun, dann ist es schwer zu sagen. Ich gehe davon aus, dass derjenige, der eine DLL verwendet, aufgrund der besseren Code-Optimierung durch Compiler bei der Erstellung von DLLs schneller sein wird. Aber das ist nur eine Vermutung, denn ich habe keinen direkten Vergleich angestellt. In der Regel habe ich in DLL nur das gemacht, was in MQL schwieriger oder unmöglich ist (zum Beispiel die Arbeit mit der im Artikel beschriebenen Datenbank). Daher haben meine Expert Advisors mit und ohne DLL-Zugriff unterschiedliche Aufgaben erfüllt.
Expert Advisors, die DLLs verwenden, haben einen Nachteil - weniger Zuverlässigkeit. Manchmal, wenn auch selten, erhalten sie die Fehlermeldung "Access violation at 0x08364576" (Speicheradressziffern sind unterschiedlich). Bei Robotern, die auf reiner MQL basieren, treten solche Fehler nicht auf. Natürlich hängt alles von einer bestimmten DLL ab - wie sie implementiert ist, wie komplex sie ist, ob alle potenziell gefährlichen Stellen in Bezug auf Speicherfehler überprüft wurden. Aber bei meinen Expert Advisors kommt es vor, dass zwei oder drei Monate lang alles gut funktioniert und dann beim Neustart einer der fünf Expert Advisors, die auf einem MT laufen, diesen Fehler im Protokoll hat. Im Falle von reinem MQL passiert das nicht.
Wenn wir den Export von Funktionen aus DLLs in C# mit dem Export aus regulären DLLs - z. B. in C++ - vergleichen, dann hat jeder Ansatz seine eigenen Vor- und Nachteile. Ich habe eine andere DLL in C++ und Qt erstellt. Sie funktionierte auch mit einer Datenbank, aber mit SQLite, nicht mit SQL Server. Es gab auch Speicherzugriffsfehler, und zwar viel häufiger als bei der .NET-DLL. Aber wenn das Projekt "aufgeräumt" wird, wenn überall, wo es nötig ist, Zeiger auf Null überprüft werden, Speicher freigegeben wird und so weiter - dann ist das Gegenteil vielleicht zuverlässiger. Aber in C# ist es irgendwie einfacher, da wird alles automatisch geprüft und freigegeben. Ich habe keine Unterschiede in der Leistung festgestellt. Allerdings wurde mein C++/Qt-Projekt nicht sehr stark ausgenutzt.
Und noch eine Frage, vielleicht haben Sie so etwas schon gemacht. Ist es möglich, ein interaktives Bedienfeld von einer C#-DLL aus zu starten, oder muss man das Bedienfeld als separates Programm erstellen und die Kommunikation mit der DLL auf irgendeine Weise sicherstellen, z. B. durch Memory Mapping oder WCF?
Ich spreche jetzt von einem lokalen Computer.
Nein, ich habe leider nicht mit interaktiven Tafeln gearbeitet. Ich kann nur spekulieren. Und ich verstehe nicht ganz, was mit "interaktives Panel" gemeint ist.
Ist es notwendig, ein MetaTrader-Fenster zu öffnen? Hier weiß ich nicht, wie es gemacht werden könnte oder ob es überhaupt gemacht werden kann.
Soll ich einfach ein Fenster öffnen und die Eingaben des Benutzers entgegennehmen? Ich habe das auch noch nicht gemacht, aber ich denke, es ist wahrscheinlich nicht schwierig. Erstellen Sie eine Klasse, die ein normales Windows Forms-Fenster definiert. Erstellen Sie in dieser Klasse eine statische , exportierbare Funktion, die das Fenster erstellt, es dem Benutzer im Dialogmodus anzeigt und es dann freigibt. Das sollte funktionieren.
Der Artikel gefällt mir - vielen Dank für die ausführliche Diskussion.
Ich hoffe, jemand kann mir mit einem Haken während der Bauzeit helfen.
C:\Users\user\source\repos\mql\MqlSqlDemo\packages\UnmanagedExports.1.2.7\tools\RGiesecke.DllExport.targets(58,3): error : Microsoft.Build.Utilities.ToolLocationHelper could not find ildasm.exe
Im Wesentlichen ist das Dienstprogramm UnmanagedExports nicht in der Lage, die ausführbare Disassembler-Datei zu finden, die für die Durchführung seiner Arbeit erforderlich ist.
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Neuer Artikel Integration von MQL-basierten Expert Advisors und Datenbanken (SQL Server, .NET und C#) :
Der Artikel beschreibt die Möglichkeit, wie ein MQL5-basierter Expert Advisors mit dem Datenbankserver Microsoft SQL Server arbeiten kann. Es wird der Import von Funktionen aus einer DLL-Datei verwendet. Die DLL wird mit der Microsoft.NET-Plattform in der Sprache C# erstellt. Die im Artikel verwendeten Methoden eignen sich, mit kleinen Anpassungen, auch für Experten, die in MQL4 geschrieben sind.
In den Foren erscheinen oft Fragen zur Integration einer Datenbank in einen Expert Advisor in MQL5. Das Interesse an diesem Thema ist nicht überraschend. Datenbanken sind sehr gut geeignet, Daten zu speichern. Im Gegensatz zu den Logdateien des Terminals verschwinden die Daten einer Datenbank nicht. Sie sind einfach zu sortieren, zu filtern und gewünschten lassen sich leicht auswählen. Eine Datenbank kann verwendet werden, um die notwendigen Informationen an einen Experten weiterzugeben - zum Beispiel bestimmte Befehle. Und vor allem - die gewonnenen Daten können aus verschiedenen Perspektiven analysiert und statistisch verarbeitet werden. Das Schreiben einer einzeiligen Abfrage reicht beispielsweise aus, um den durchschnittlichen und den Gesamtgewinn für eine bestimmte Zeit für jedes Währungspaar zu ermitteln. Und stellen Sie sich nun vor, wie lange es dauern würde, wenn Sie dies für die Handelshistorie eines Kontos im Terminal manuell einrichten müssten.
Leider bietet MetaTrader keine integrierten Werkzeuge für die Verwendung von Datenbankservern. Das Problem kann nur durch den Import von Funktionen aus DLL-Dateien gelöst werden. Die Aufgabe ist nicht einfach, aber machbar.
Starten Sie den Experten und ändern Sie die Werte der Verbindungszeichenfolge in die Zugriffsparameter Ihres Datenbankservers. Wenn alles richtig gemacht wird, gibt der Experte folgendes im Protokoll aus:
2018.07.10 20:36:22.187 MqlSqlDemo (EURUSD,H1) Created table in database.
2018.07.10 20:36:22.427 MqlSqlDemo (EURUSD,H1) Data written to table.
2018.07.10 20:36:22.569 MqlSqlDemo (EURUSD,H1) Number read from database: 1
2018.07.10 20:36:22.586 MqlSqlDemo (EURUSD,H1) String read from database: Test
Die Verbindung zur Datenbank, das Ausführen der SQL-Kommandos, das Lesen und Schreiben der Daten — alles wurde erfolgreich ausgeführt.
Autor: Сергей Ткаченко