Classes : Directives et meilleures pratiques d'ordre général
Date de publication : juillet 2016
S’applique à : System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager
Utilisez les instructions et meilleures pratiques suivantes pour la personnalisation des classes dans Outil de création de System Center 2012 – Service Manager.
Convention d'affectation de noms pour les définitions de types
La convention d'affectation de noms applicables aux modèles de schémas Service Manager est basée sur la convention utilisée pour les espaces de noms .NET.
Conventions d'affectation de noms de base
La convention d'affectation de noms de base est CompanyName.TechnologyArea.ProductName.FunctionalityArea.Name, où :
ProductName est facultatif. Vous pouvez l'utiliser si la définition ne dépend d'aucun produit.
FunctionalityArea est facultatif. Vous pouvez l'utiliser si la définition s'applique à plusieurs sections.
Name indique la signification de la classe, et non la hiérarchie d'héritage.
Exemples : Microsoft.AD.Printer, Microsoft.Windows.Computer, System.Knowledge.Article, System.WorkItem.Incident et System.StarRating.Average.
L'espace de noms System
L'espace de noms System fait référence aux définitions qui sont indépendantes de Microsoft et de Windows. Il s'agit généralement de définitions de base desquelles dépendent des applications Windows ou Unix. Ces définitions de base doivent être indépendantes de la société.
Utilisez les instructions suivantes concernant le préfixe System :
System.Computer représente tout type d'ordinateur et n'est pas spécifique à un fournisseur.
Utilisez le préfixe System si vous pensez que d'autres personnes définiront des schémas sur cet espace de noms.
Notez que Microsoft.Windows.Computer ne commence pas par System, bien que la plupart des applications Windows (quel que soit le fournisseur qui le définit) dépendent de cette définition.
Meilleures pratiques en matière de dénomination des classes
Utilisez les meilleures pratiques suivantes lorsque vous nommez des classes :
Ne créez pas deux classes différentes (même si elles se trouvent dans deux packs d'administration différents), car cela aurait pour résultat le stockage de valeurs clés identiques pour différents objets des deux classes.
Lorsque vous étendez une classe, assurez-vous toujours que les noms d'extension de classe sont uniques parmi les packs d'administration. Si possible, utilisez des noms d'extension de classe explicites.
Lorsque vous étendez une classe, ne définissez pas une propriété avec un ID qui est déjà en cours d'utilisation dans cette classe.
N'utilisez pas de points dans le nom des propriétés d'une classe personnalisée.
Si vous ajoutez un calcul nommé personnalisé lors de la création d'un cube, faites précéder le nom du calcul nommé par NC_. Cela réduira les risques d'utiliser un nom de propriété qui existe déjà.
Ne créez pas trop de classes
La création d'un trop grand nombre de classes peut entraîner une complexité inutile, sans présenter d'avantage. En général, il est recommandé d'utiliser le moins de classes possible pour obtenir les résultats désirés. À l'exception des classes abstraites, si une classe ne va pas être la cible d'un flux de travail ni être utilisée pour stocker des données, alors, il est préférable de ne pas la créer. Si deux classes sont semblables, envisagez également de n'utiliser qu'une seule classe pour elles deux, par exemple, en utilisant une propriété pouvant contenir des valeurs différentes.
N'utilisez pas de propriétés qui doivent être mises à jour trop fréquemment
Les valeurs des propriétés ne doivent être modifiées que rarement après leur première définition. Les valeurs des propriétés peuvent être amenées à changer fréquemment lorsqu'un connecteur personnalisé ou autre élément personnalisé met à jour par programme la base de données Service Manager. Ces scénarios peuvent entraîner une mise à jour des valeurs de propriété trop fréquente, tel que toutes les 10 à 15 minutes (ou moins) pour un grand nombre d'objets.
Ces changements fréquents des valeurs de propriété peuvent avoir un léger impact sur les performances des flux de travail, ainsi que sur les performances d'autres éléments. Ceci s'explique par le fait que le système conserve le suivi de ces modifications dans l'historique. En outre, en fonction de la propriété en question, ces modifications peuvent ajouter une quantité importante de données à traiter et à stocker dans l'entrepôt de données.
N'étendez pas les classes abstraites
Dans System Center 2012 - Service Manager, il n'est pas possible d'étendre une classe abstraite. Si vous avez besoin d'étendre une classe abstraite, vous pouvez effectuer l'une des opérations suivantes :
Créez une classe avec les propriétés de votre choix, puis créez une relation entre la nouvelle classe et la classe abstraite.
Étendez chacune des classes concrètes appropriées, dérivées de la classe abstraite.
Améliorez la recherche simple pour les classes d'éléments de travail
Lorsque vous définissez une classe personnalisée dérivée de la classe « System.WorkItem », il est recommandé de stocker la propriété DisplayName de cette classe au format suivant : WorkItem.ID<ESPACE>WorkItem.Title.
Cela permet d'améliorer la recherche simple. La recherche simple effectue uniquement des recherches dans la propriété DisplayName. En outre, si vous incluez de manière explicite les valeurs de propriété Title et ID de la valeur de propriété DisplayName, les résultats de la recherche simple s'en verront améliorés. Ceci s'explique par le fait que l'utilisateur peut effectuer une recherche à l'aide d'un mot du titre ou d'un ID.
Voir aussi