In dieser kurzen Serie möchte ich einige der einfachen – und nicht ganz so einfachen – Möglichkeiten behandeln, Mendix Apps können effizienter gestaltet werden. Das ideale Ergebnis sollte eine App sein, die ihre Aufgabe in möglichst kurzer Zeit erledigt und möglichst wenig Ressourcen verbraucht.

Immer?

Nein.

Manchmal gibt es eine trade-off zwischen eine Option, die lesbar und wartbar oder eine höher optimierte Version, die möglicherweise genial und Mehr effizient aber schwer zu verstehen und die für Sie oder einen anderen Entwickler, der den Code künftig pflegen muss, ein Problem darstellen.

Dies ist eine Ermessensentscheidung, die das Team während der Entwicklungsphase oder bei der Untersuchung eines Leistungsproblems treffen muss. Qualitativ hochwertige Kommentare oder Dokumentationen können möglicherweise zum Verständnis unklaren Codes beitragen.

Ebenfalls, desto häufiger läuft etwas, desto größer ist die Wahrscheinlichkeit Nutzen ab Verbesserung der Effizienz. Eine Aktion, die so optimiert werden könnte, dass sie nur 5 statt 10 Minuten dauert, aber nur einmal im Monat ausgeführt wird, sollte bei der Suche nach Effizienzgewinnen wahrscheinlich weniger im Mittelpunkt stehen, während ein Effizienzgewinn von einer halben Sekunde bei einer Aktion, die tausende Male am Tag ausgeführt wird, sicherlich eine höhere Priorität hat.

Goldene Oldies

Einige Designmuster innerhalb Mendix wurden bereits zuvor hervorgehoben, sind aber einen erneuten Besuch wert, da sie manchmal sowohl von neuen als auch von erfahrenen Entwicklern übersehen werden.

Schleife De Schleife

Beim Verwenden einer Schleife zum Erstellen oder Ändern von Objekten in einem Mikrofluss sammle die neue/geänderte Objekte des gleichen Typs in einem Liste , verpflichten diese Liste aussen die Schleife.

Statt:

Sie können verwenden:

Dies bedeutet, dass es ein einzelnes Commit für Order-Objekte und ein weiteres für OrderUpdateAudit-Objekte, die am Ende des Prozesses für die neuen und geänderten Objekte verwendet werden. Commits können teuer sein Da für jeden dieser Schritte Ihre App einen Roundtrip zur Datenbank ausführen muss und jeder Roundtrip einen Overhead verursacht, verringert die Bündelung der Commits die Anzahl der Roundtrips und somit den Overhead.

Lassen Sie Ihre Aggregate fliegen!

Der Mendix Die Laufzeit geht zu lange, um die Datenbankabfragen zu optimieren, die sich aus dem von Ihnen geschriebenen Low-Code ergeben. In Ihren Mikroflüssen können Sie beispielsweise einen Auflisten der aggregierten Aktivität unmittelbar nach einer Abrufaktivität:

Dies verursacht die Laufzeit zu eine einzelne Anweisung ausführen mit der Datenbank verglichen, die den Durchschnittswert des OrderValue für die Bestellung berechnet. Die Auftragsdatensätze werden überhaupt nicht in die App abgerufen und die OrderList wird nicht tatsächlich erstellt. Dadurch wird die Ausführung schneller.

Es ist jedoch möglich, diese Optimierung zu unterbrechen, indem die generierte Liste anschließend wiederverwendet wird.

Jetzt wird die OrderList nach dem Ausführen des Aggregats erneut verwendet (als Datenquelle für die IteratorOrder-Schleife). Dies bedeutet, dass Mendix kehrt zum Standardverhalten zurück und führt den Abruf aus, um alle Datensätze in die Bestellliste zu laden. Anschließend wird der Durchschnitt berechnet, indem die Datensätze in dieser Liste durchsucht werden.

Unter diesen Umständen kann es durchaus beschleunigt das laufen lassen Abrufen Aktivität zweimal — einmal für die Aggregat zu verwenden und noch einmal zu Holen Sie sich die RekordlisteDies trifft insbesondere in dieser Abbildung zu, da der zweite Abrufvorgang (der nun die Quelle für die IteratorOrder-Schleife ist) nur ausgeführt wird, wenn der berechnete Durchschnitt angemessen ist. Wenn der Durchschnitt also niedrig ist, wird die Liste überhaupt nicht abgerufen.

Verwendung von Nanoflows anstelle von Mikroflows

Mikroflüsse sind leistungsstarke Code-Aktionen, die ausgeführt werden auf dem Mendix Server, häufig ausgelöst durch den Benutzer Mendix Klient. Nanoströme können viele der gleichen Aktivitäten wie Microflows ausführen, obwohl ihre Funktionsweise in einigen Fällen von der von Microflows abweicht. Der große Unterschied besteht darin, dass ein Nanoflow im Mendix Kunden (der Browser oder die native App des Benutzers), was einem Nanoflow einen großen Effizienzvorteil gegenüber einem Microflow mit ähnlicher Funktion verschaffen kann.

Dieser Microflow wird über eine Schaltfläche auf der Benutzeroberfläche aufgerufen und implementiert eine Geschäftsregel, die das angezeigte Objekt aktualisieren kann. Durch Klicken auf die Schaltfläche wird ein Aufruf über den Mendix Der Client sendet zurück an die App auf dem Server und fordert die Ausführung des Microflows und die Rückgabe der Ergebnisse an den Client an.

Dieser Nanoflow macht dasselbe. Funktionell ist er fast identisch mit dem Microflow, aber der gesamte Vorgang wird im Benutzer ausgeführt. Mendix Client, sodass der Aufruf des Clients an den Server, die Ausführung des Codes auf dem Server und die Rückgabe der Ergebnisse an den Client nicht erfolgen. Dies reduziert den Netzwerkverkehr und verhindert, dass der Server unterbrochen wird, um die Änderungen für den Benutzer durchzuführen.

Die Verwendung von Nanoflows ist nicht immer eine gute Idee. Wenn Ihr Nanoflow als Teil seiner Funktion einen Microflow aufrufen muss, sparen Sie möglicherweise nichts, da weiterhin Netzwerkinteraktionen und Serverunterbrechungen auftreten. Wenn Ihr Nanoflow mehrere Microflows aufrufen oder weitere Daten aus der Datenbank abrufen muss, um seine Funktion auszuführen, ist die Verwendung eines Nanoflows anstelle eines Microflows wahrscheinlich kontraproduktiv.