[DavidZed]

Hello Sebastien Brandeis ,

Pour Dataverse, mettre en place des règles de nommage sur le ‘shema name’ présente assez peu d’intérêt, voire peut se révéler handicapant dans certains cas.

Exemple quand tu te retrouves à devoir manipuler les colonnes dans l’pp studio avec des showcolumns / dropcolumns etc… il est très pratique de pouvoir déduire le shema name facilement (Préfixe de l’éditeur + display Name sans les espaces et caractères spéciaux)

CommentID=4b3HTOkHD9cDrN2, PostID=Bcjo0E7y9lwWty4

[Alexandre]

Mes champs je les nomme en parfait français (cible app uniquement francophone) mais je n’oublie de jeter un oeil sur le nom technique qui en découlera pour qu’il soit intelligent et cohérent (simple à retrouver, comme le précise DavidZed .

C’est un gain de temps énorme quand tu vas mettre un formulaire puisque les étiquettes porteront le nom de tes champs.

CommentID=BQh8fkDWvt9a19D, PostID=Bcjo0E7y9lwWty4

[R3dKap]

Sebastien Brandeis, de mon côté, sur Dataverse :

• Au moment de créer ma solution je crée un éditeur dont le préfixe est parlant pour la solution concernée

Ainsi, je sais déjà que tous les noms de schéma de mes objets commenceront par ce préfixe suivis d’un “_”.

• Ensuite tout est en minuscule avec des “_” pour séparer les mots et essayant d’être le plus parlant possible (j’ai ouï dire que les minuscules étaient recommandées par MS)

Du coup, comme le souligne DavidZed, c’est très facile à retrouver dans l’éditeur Power Apps lors de l’utilisation des fonctions du type ShowColumns().

Et pour moi, pas besoin d’avoir l’info du type de données dans le nom du schéma… Mais ce n’est qu’un avis perso…

CommentID=eRkg1kIq589DyEC, PostID=Bcjo0E7y9lwWty4

[Tanguy Touzard]

Si on essaye de suivre les nomenclatures de Microsoft dans Dataverse, il faudrait plutôt écrire les noms en PascalCase (sans compter le préfixe), ce qui donnera le nom de schéma. Le nom logique sera automatiquement remis en minuscule. Pourquoi me direz-vous? il existe cette notion de Early Bound Entities qui sert à générer le modèle objet CRM en .Net pour les développeurs et qui reprend le nom de schéma. Donc si vous utilisez du PascalCase, vous aurez des noms de classes (table) et propriétés (colonnes) respectant les bonnes pratiques de nommage .Net, en plus d’avoir une cohérence pour le low code/no code.

Ensuite, en suivant toujours la logique de ce que fait MS (quand ils le font bien), certains type de champ doivent être préfixé/suffixé:

• Lookup : doit finir par Id => prefix_TableLieeId

• Choix : doit finir par Code => prefix_MaListeCode

• Booléen : doit représenter une affirmation => prefix_EstAcceptee

• Date : contient le mot Date ou fait référence à une action => prefix_DateDebut ou prefix_SigneLe

Pour les autres types, le nommage en lui-même devrait suffire à identifier le type.

Voilà, c’est ma petite expérience de 19 ans de Dynamics CRM/365 en tant que développeur principalement mais aussi de citizen developer maintenant 🙂

CommentID=mALztDI0zC5iij9, PostID=Bcjo0E7y9lwWty4