Conseils pour l'écriture du code (code)

Conseils pour écrire le code métier

L’évaluation des expressions booléenne est optimisée

Le compilateur optimise l’évaluation des expressions booléennes, vous pouvez donc en tenir compte dans l’écriture du code :

if Assigned(role) and (role.Code=’X’) then ...

Le compilateur n’optimise pas la réutilisation des objets

La traversée des relations à travers la notation pointée est une opération « coûteuse » à l’exécution ; du fait que le compilateur n’optimise pas le code généré dans le sens de la réutilisation, vous avez intérêt à utiliser des variables intermédiaires pour stocker les objets accédés fréquemment à travers une relation pointée :

Exemple

For idx :=0 to RoleList.Count-1 do
 begin
    Obj := RoleList[idx].roleRef.roleRef ;
    If (obj.Code = 'X') or (obj.code = 'Y') then 
    Begin
       Montant.value := obj.montant.TCValue;
       ...
    End ;
 end ;

N’utilisez pas inutilement des blocs try except ou finally

Les blocs try except finally constituent un mécanisme extrêmement élégant pour réaliser la prise en compte des erreurs à l’exécution. Toutefois ce mécanisme à un « coût » non négligeable en terme de code généré. Le moteur de script gérant automatiquement les compteurs de références des objets métiers et techniques, il est rarement nécessaire, en dehors de la gestion des transactions, d’utiliser des blocs de gestion d’exception.

N’oubliez pas les « propriétés » des attributs métiers

Les attributs métiers exposent des « propriétés » qui donnent accès aux différentes propriétés de l’attribut. Une erreur commune consiste à « oubliez » la propriété dans l’écriture du code.

Exemple

if enumAttribut = ETAT_OK then ...

Cette expression compare l’objet enumAttribut à la constante ETAT_OK, ce qui n’est manifestement pas ce que le développeur souhaitait ; la syntaxe correcte était :

If enumAttribut.value = ETAT_OK then ...

Note : Le compilateur détecte généralement une erreur de type lors de cette confusion.

Corriger les erreurs de type

Le compilateur contrôle l'intégrité des types de données (à partir de la version 5.50) mais génère des alertes et pas des erreurs. Corriger ces erreurs de type qui sont généralement le reflet d'une erreur de programmation.

Attention : A l'avenir les erreurs de types seront remontées comme des erreurs et non pas comme des alertes.

Conseils pour écrire les règles métiers

N’utilisez pas de curseur

Le framework Ligne 1000 gère automatiquement les sessions de base de données. Sur certaines bases de données les curseurs peuvent nécessiter l’utilisation d’une session dédiée pour s’exécuter. Il en résulte que dans certains cas il peut exister plusieurs sessions concurrentes de base de données qui peuvent, sous certaines conditions, se bloquer mutuellement.

Pour cette raison il est fortement déconseillé d’utiliser des curseurs dans l’écriture des règles métiers.

Respectez les types des règles

Le framework Ligne 1000 exécute automatiquement les règles métiers en fonction de leurs types et de l’état des objets. Il est donc important de respecter l’usage prévu des règles métiers et de ne pas détourner l’utilisation d’une règle à d’autres fins.

Par exemple, une règle d’erreur est fait pour détecter une erreur et peut être exécutée sur la modification de l’attribut sur lequel elle porte ; elle ne doit pas être utilisée pour réaliser une action particulière sur la modification de l’attribut.

Attention : A partir de la version 5.60 le framework interdit les modifications durant la phase de vérification des règles d'intégrité. En cas de modification durant cette phase une exception est levée.

Evitez de créer des transactions

Normalement les règles métiers n’ont pas besoin de créer des transactions. Toutefois si vous avez besoin de démarrer une transaction dans une règle métier, une règle d’action par exemple, respectez les règles de gestion des transactions.

Ecriture des règles dérivées

Règles dérivées des attributs simples

Pour écrire des règles dérivées portant sur des attributs simples, placez la valeur résultat de l’attribut dans la variable « Result » de la règle.

Exemple Ce code décrit une règle de dérivation portant sur un attribut dérivé CreditEuro de type currency qui prendra la valeur de l’attribut CreditTenu si estEuro est True ou la valeur 0 si estEuro est False.

begin
  if estEuro 
     then result := CreditTenue
     else result := 0.0 ;
end ;

Règles portant sur des attributs frameworks

Les attributs frameworks sont gérés par des objets techniques créés lors de la création de l’instance de l’objet. Dans le cas d’attributs frameworks dérivés, la règle dérivée doit modifier directement les différentes propriétés de l’attribut. La valeur « Result » de la règle n’est pas utilisée.

Exemple L’attribut FraisAffecte est de type « Montant en devise ». Pour attribuer une valeur au paramètre non persistant FraisAffecte on utilise FraisAffecte.value :=vFraisAffecte ;

var iFra :Integer ; vFraisAffecte :Currency ;
begin
  Result := FALSE ;
  vFraisAffecte :=0 ;
  if assigned(compteBancaireEts) then
  begin
    FraisAffecte.oidDevise :=compteBancaireEts.oidDevise ;
    For iFra :=0 to FraisReglementList.count-1 do
    begin
      vFraisAffecte :=vFraisAffecte+FraisReglementList[iFra].montant.value ;
    end ;
    FraisAffecte.value :=vFraisAffecte ;
  end ;
end ;

Remarquez la différence pour les attributs :

• simple : Result := « expresion » ;
• montant : « nomMontant ».valeur := « expresion » ;

Règles portant sur des attributs tableaux

Pour un attribut tableau dérivé la règle de dérivation est appelée pour chaque élément du tableau. Il est donc nécessaire de tenir compte des indices de l’élément calculé dans l’écriture de la règle de dérivation. Pour cela une propriété « Indices » est disponible dans les règles de dérivation :

Property Indices[iDimension :Integer] :Integer ;

Elle retourne pour une dimension donnée l’indice de l’élément en cours de calcul.

Exemples

Pour un tableau d’entiers dérivés à une dimension retourne l’indice de l’élément :

Result := Indices[1];

Pour un tableau d’entiers dérivés à deux dimensions retourne le produit des indices de l’élément :

Result := Indices[1]*Indices[2];

Pour un tableau d’entiers dérivés à deux dimensions retourne la valeur d’un autre attribut dérivé à trois dimensions dont le premier indice est constant :

Result := Tableau3D[0,Indices[1],Indices[2]];

Note : Les déclencheurs définis sur un tableau dérivé invalident l’ensemble des éléments du tableau.

— Code métier — Développement DSM —