Dans cette courte série, je souhaite aborder quelques-unes des manières simples – et pas si simples – qui Mendix Les applications peuvent être rendues plus efficaces. Le résultat idéal devrait être une application qui effectue son travail le plus rapidement possible et consomme le moins de ressources possible.

Toujours?

Non.

Parfois, il y a un compromis jusqu'à XNUMX fois une option qui est lisible et maintenable ou une version plus optimisée qui peut être ingénieux et plus des actifs mais difficile à comprendre et ce qui constituera un problème pour vous ou pour un autre développeur devant maintenir le code à l'avenir.

Il s'agit d'une décision de jugement qui doit être prise par l'équipe au moment où le développement est en cours, ou lorsqu'un problème de performance est étudié, et il se peut que des commentaires ou une documentation de bonne qualité aident à promouvoir la compréhension d'un code peu clair.

Aussi, les plus souvent quelque chose fonctionne, plus la probabilité est grande profiter à partir de améliorer son efficacité. Une action qui pourrait être optimisée pour prendre 5 minutes au lieu de 10 mais qui n'est exécutée qu'une fois par mois devrait probablement être moins ciblée lors de la recherche de gains d'efficacité, alors qu'un gain d'efficacité d'une demi-seconde dans une action qui s'exécute des milliers de fois par jour est certainement une priorité plus élevée.

Oldies d'or

Quelques modèles de conception au sein Mendix ont déjà été mis en évidence, mais méritent d'être revisités car ils sont parfois oubliés par les développeurs débutants et expérimentés.

Boucle De Boucle

Lors de l'utilisation d'une boucle pour créer ou modifier des objets dans un microflux recueillir le objets nouveaux/modifiés du même type dans un liste et commettre cette liste au contrôle le boucle.

Au lieu de:

Vous pouvez utiliser:

Cela signifie qu'il y a un seul commit pour les objets Order et un autre pour les objets OrderUpdateAudit utilisés à la fin du processus pour les objets nouveaux et modifiés. Les engagements peuvent être coûteux étant donné que chacun d'entre eux nécessite que votre application exécute un aller-retour vers la base de données et que chaque aller-retour entraîne une surcharge, le regroupement des commits réduit le nombre d'allers-retours et donc la surcharge.

Laissez vos agrégats voler !

Le Mendix l'exécution va trop loin pour optimiser les requêtes de base de données résultant du code faible que vous écrivez, par exemple dans vos microflux, vous pouvez placer un lister les activités globales immédiatement après une activité de récupération:

Cela provoque le d'exécution à exécuter une seule instruction par rapport à la base de données qui calculera la valeur moyenne de OrderValue sur Order. Les enregistrements Order ne seront pas récupérés dans l'application et OrderList ne sera pas réellement produit. Cela rendra l'exécution plus rapide.

Il est toutefois possible de rompre cette optimisation en réutilisant ultérieurement la liste générée.

Maintenant, la liste de commandes est à nouveau utilisée après l'exécution de l'agrégat (en tant que source de données pour la boucle IteratorOrder) et cela signifie que Mendix revient au comportement standard et exécute la récupération pour charger tous les enregistrements dans OrderList, puis calcule la moyenne en parcourant les enregistrements de cette liste.

Dans ces circonstances, il se pourrait bien que plus rapide pour exécuter le Récupérer activité deux fois — une fois pour le agrégat à utiliser et encore une fois à obtenir la liste des enregistrements. Ceci est particulièrement applicable dans cette illustration car la deuxième récupération (qui est maintenant la source de la boucle IteratorOrder) n'est exécutée que si la moyenne calculée est adéquate, donc si la moyenne est faible, la liste n'est pas récupérée du tout.

Utilisation des nanoflux au lieu des microflux

Microflux sont des actions de code puissantes qui sont exécutées sur le Mendix serveur, fréquemment provoqué par l'utilisateur Mendix Client. Nanoflux peuvent effectuer de nombreuses activités identiques à celles des microflux, bien que dans certains cas, leur fonctionnement diffère de celui des microflux. La grande différence est qu'un nanoflux s'exécute dans le Mendix Projet (le navigateur de l'utilisateur ou l'application native) qui peut donner à un Nanoflow un gros avantage en termes d'efficacité par rapport à un Microflow exécutant une fonction similaire.

Ce microflux est appelé à partir d'un bouton de l'interface utilisateur et implémente une règle métier qui peut mettre à jour l'objet affiché. Cliquer sur le bouton provoque un appel à partir de l' Mendix Le client revient à l'application sur le serveur demandant que le Microflow soit exécuté et que les résultats soient renvoyés au client.

Ce Nanoflow fait la même chose. Fonctionnellement, il est presque identique au Microflow, mais toute l'opération s'exécute dans le navigateur de l'utilisateur. Mendix Client afin que l'appel du Client au serveur, l'exécution du code sur le serveur et le retour des résultats au Client ne se produisent pas. Cela réduit le trafic réseau et évite que le serveur soit interrompu pour effectuer les modifications pour l'utilisateur.

L'utilisation de Nanoflows n'est pas toujours une bonne idée. Si votre Nanoflow doit appeler un Microflow dans le cadre de sa fonction, vous ne risquez pas de vous épargner quoi que ce soit car l'interaction réseau et l'interruption du serveur se produiront toujours. Si votre Nanoflow doit appeler plusieurs microflows ou doit récupérer d'autres données de la base de données pour exécuter sa fonction, il est probable que l'utilisation d'un Nanoflow au lieu d'un Microflow soit contre-productive.