Classes: Diretrizes gerais e práticas recomendadas
Publicado: julho de 2016
Aplicável a: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager
Use as diretrizes e práticas recomendadas a seguir quando você estiver personalizando classes no System Center 2012 – Ferramenta de Criação do Service Manager.
Convenções de nomenclatura para definições de tipo
A convenção de nomenclatura de modelo de esquema do Service Manager é baseada na convenção de nomenclatura de namespaces do .NET.
Convenções básicas de nomenclatura
A convenção básica de nomenclatura é CompanyName.TechnologyArea.ProductName.FunctionalityArea.Name, em que:
ProductName é opcional; use-o se a definição dor independente de qualquer produto específico.
FunctionalityArea é opcional; use-a se a definição puder ser aplicada a áreas diferentes.
Name reflete o significado da classe, não a hierarquia de herança.
Exemplos: Microsoft.AD.Printer, Microsoft.Windows.Computer, System.Knowledge.Article, System.WorkItem.Incident e System.StarRating.Average.
O System Namespace
O namespace System refere-se a definições que são independentes da Microsoft e Windows. Geralmente, isso se aplica às definições de base das quais os aplicativos Windows ou Unix dependem. Essas definições de base devem ser independentes da empresa.
Use as seguintes diretrizes para o prefixo System:
System.Computer representa qualquer tipo de computador e não é específico do fornecedor.
Use o prefixo System se você espera que outros usuários definam esquemas sobre esse namespace.
Observe que Microsoft.Windows.Computer não inicia com System, embora a maioria dos aplicativos Windows (independentemente do fornecedor que a define) confie nessa definição.
Práticas recomendadas para nomear classes
Use as seguintes práticas recomendadas quando você está nomeando classes:
Não crie duas classes separadas (mesmo se elas estiverem em dois pacotes de gerenciamento diferentes) que resultarão em valores de chave idênticos sendo armazenados para objetos diferentes das duas classes.
Quando você estiver estendendo uma classe, sempre verifique se os nomes de extensão de classe são exclusivos nos pacotes de gerenciamento. Se possível, use nomes significativos de extensão de classe.
Quando você estiver estendendo uma classe, não defina uma propriedade com uma ID que já esteja em uso nessa classe.
Não utilize pontos em nomes de propriedades de uma classe personalizada.
Se você adicionar um cálculo nomeado personalizado ao criar um cubo, preceda o nome do cálculo nomeado com NC_. Isso reduzirá a possibilidade de usar um nome de uma propriedade que já existe.
Não criar muitas classes
A criação de muitas classes pode resultar em complexidade desnecessária com o valor mínimo. Uma regra recomendada é usar o menor número de classes para alcançar os resultados desejados. Ao contrário das classes abstratas, se uma classe não for definida como o destino de qualquer fluxo de trabalho ou for usada para armazenar dados, provavelmente não deverá ser criada. Além disso, se duas classes forem semelhantes, considere a possibilidade de usar uma única classe para ambas, possivelmente usando uma propriedade que possa reter os valores para qualquer diferença.
Não usar propriedades que atualizam com muita frequência
Valores de propriedade raramente devem se alterar depois de serem populados pela primeira vez. Uma possível causa para as alterações frequentes do valor de propriedade é um conector personalizado ou qualquer outra personalização que atualize de forma programática o banco de dados do Service Manager. Esses cenários podem fazer com que possivelmente os valores de propriedade sejam atualizados com muita frequência, como a cada 10 a 15 minutos ou menos para um grande número de objetos.
Essas alterações frequentes nos valores de propriedade podem impactar um pouco o desempenho dos fluxos de trabalho e eles podem ter outros impactos de desempenho. Isso ocorre porque o sistema mantém controle sobre as alterações no histórico. Além disso, dependendo da propriedade que está sendo alterada, essas alterações podem adicionar uma quantidade significativa de dados a serem processados e armazenados pelo data warehouse.
Não estender uma classe abstrata
No System Center 2012 - Service Manager, você não pode estender uma classe abstrata. Se você precisa estender uma classe abstrata, é possível fazer o seguinte:
Criar uma nova classe com as propriedades que deseja adicionar e criar uma relação entre a nova classe e a classe abstrata.
Estender cada uma das classes concretas relevantes que derivam da classe abstrata.
Melhorar a pesquisa simples de classes de item de trabalho
Quando você define uma classe personalizada que é derivada da classe “System.WorkItem”, é recomendável armazenar a propriedade DisplayName dessa classe no seguinte formato: WorkItem.ID<SPACE>WorkItem.Title.
Isso melhora a pesquisa simples. A pesquisa simples procura apenas a propriedade DisplayName e, ao incluir explicitamente os valores de propriedade Title e ID no valor de propriedade DisplayName, os resultados da pesquisa simples serão melhorados. Isso ocorre porque o usuário pode pesquisar por uma palavra no título ou por uma ID.
Consulte também