mORMot: ORM und DocVariant kurz vorgestellt

[Der schöne Günther]

Ich habe mich vor mORMot bislang immer gedrückt, auch wenn ein paar mal ein paar nützliche Dinge für mich drin gewesen wären.

Vielleicht lag ich falsch, aber ich habe es als eine riesige Bibliothek, wo jede Unit immer von zwei Dutzend anderen Mormot-Units abhängt, in Erinnerung. Dann noch mit jede Menge obskurem Code in initialization/finalization-Abschnitten und ich verstehe überhaupt nicht, wo sich das alles einklinkt. Das hat mich zu sehr an die JCL erinnert und ich bin weggelaufen.

Ist das immer noch so? War mein damaliger Eindruck falsch?

[mytbo]

Zitat von Der schöne Günther:

Ist das immer noch so? War mein damaliger Eindruck falsch?

Die Frage ist nicht einfach zu beantworten, weil ich nicht weiß, ob du deine Erfahrungen mit mORMot Version 1 oder 2 gemacht hast. Allgemein: Ja, mORMot ist riesig, aber in seiner Gesamtheit ein wunderbares Werk der Programmierkunst. Die gesamte Umsetzung von mORMot1, vor allem die Formatierung des Quelltextes, war für mich eine Herausforderung. Ich musste mir jede Funktion zweimal ansehen und den Quelltext im Geiste mehrfach umformatieren. Das lag an der evolutionären Entstehung der Bibliothek, wahrscheinlich auch daran, dass Arnaud Performance einen besonders hohen Stellenwert einräumt und dem vieles unterordnet. mORMot2 ist sehr gut strukturiert und die Richtlinien für die Formatierung des Quelltextes orientieren sich am Gewohnten.

Was mORMot schon immer ausgezeichnet hat, ist der "sowohl - als auch" Gedanke. In der Anfangszeit meiner Nutzung, ab Ende 2009, habe ich mORMot für einige Jahre als Ergänzung und später als Ersatz der JCL eingesetzt. Erst 2013 wurde von mir der erste Server realisiert. Den Gedanken, mORMot als riesige Funktionsbibliothek einzusetzen, würde ich deshalb nicht als Fehler erachten. Ziel ist es doch, die Anzahl der Abhängigkeiten zu externen Bibliotheken zu reduzieren. Das kann man IMHO nur durch hochwertige multifunktionale Bibliotheken erreichen. Die Anzahl der einzubindenden Units einer Bibliothek spielt dabei für mich keine Rolle. Die mORMot2 Units haben ein stringentes Namensschema. Man findet sich schnell zurecht.

mORMot hat viele Funktionen und mehr als 74M automatisierte Tests. Sich Stück für Stück einzuarbeiten halte ich für den Weg, der am schnellsten Erfolg verspricht. Steht man vor einer konkreten Aufgabe und glaubt, mORMot in wenigen Stunden oder Tagen zu erlernen, wird man wahrscheinlich scheitern.

Bis bald...
Thomas

[Der schöne Günther]

Alles klar, wahrscheinlich wird das noch "Version 1" gewesen sein, damals.
Mir ging es nicht um die Anzahl der Units, sondern dass einfach nicht überschaubar war, was da eigentlich abgeht, weshalb kann eine Routine nicht mit einer mit einer normalen StringList oder String-Array arbeiten, sondern erfindet sich wieder einen eigenen Typ, der nur in dieser Bibliothek existiert? Solche Dinge halt...

Zitat von mytbo:

und mehr als 74M automatisierte Tests

Du meintest hoffentlich 74.000 und nicht 74.000.000? Hoffentlich, denn sonst hätte ich Angst.

Wenn ich eines Tages mal Zeit habe schaue ich mir das bestimmt mal näher an. Vielen Dank für die ausführliche Erklärung.

[mytbo]

Zitat von Der schöne Günther:

Zitat von mytbo:

und mehr als 74M automatisierte Tests

Du meintest hoffentlich 74.000 und nicht 74.000.000? Hoffentlich, denn sonst hätte ich Angst.

Aktuell: Total assertions failed for all test suits: 0 / 74.197.472
Mich beruhigt das.

Bis bald...
Thomas