O que fazer e o que não fazer: contexto Webdynpro.

parece-me que essas regras visam a melhoria do desempenho.

eu tenho algumas observações sobre um casal dessas regras:

• Sem qualquer exigência(uso em Múltiplas do Controlador) não criar um Contexto no Componente controlador de nível, Se necessário criar contextos locais, por exemplo, em vistas

O componente controlador é o seu hub central para o seu contexto. Se, a qualquer momento, você tiver um nó de contexto compartilhado em várias visualizações, deverá criar o nó no controlador de componente e mapeá-lo para outras visualizações.

nós específicos para uma determinada visualização podem ser criados diretamente no contexto da visualização, mas para legibilidade e uniformidade, geralmente escolho centralizar todos os meus nós de contexto e métodos de fornecimento no controlador de componente.

• Usar singleton nós se elementos aninhados (detalhe principal) são necessários

Singleton nós são bons para o desempenho, porque você só manter uma instância do nó na memória, ao invés de ter várias instâncias para cada (inativo) objecto principal. No entanto, é melhor você saber o que está fazendo, porque se você entrar na situação em que precisa de vários elementos pai ativos (repetidor de linha, tabelas aninhadas, árvores, tabelas de seleção múltipla…) o nó singleton irá despejar seu aplicativo.

se você não conhece bem o princípio dos nós singleton, ou quando o desempenho não é um problema, não use Nós singleton.

• não use atributos dinâmicos (IF_WD_CONTEXT_NODE_INFO – >ADD_ATTRIBUTE)

se você puder usar atributos de contexto definidos estaticamente, use atributos estáticos. No entanto, haverá situações em que você terá que criar dinamicamente seu contexto. Nesses casos, você não tem outra escolha além de adicionar atributos dinâmicos. No entanto, concordo que você deve evitar a programação de contexto dinâmico (e programação de visualização dinâmica), tanto quanto possível.

• Use dados com estrutura de contexto para BIND_TABLE

não é um requisito difícil, internamente, as operações de ligação usam um movimento correspondente e mantêm a tabela original em uma variável de sombra. Embora o movimento correspondente seja supostamente ruim para o desempenho. (Eu digo supostamente, porque fiz testes de mim mesmo e não consegui encontrar nenhuma diferença significativa)

• atualize o contexto apenas se os dados realmente tiverem que ser atualizados

depende do que você quer dizer com atualização?

• não crie cadeias de mapeamento de contexto longas.

?

• Use as funções de log de alteração de contexto para detectar a entrada do Usuário. Isso tem benefícios de desempenho específicos, enquanto um usuário do aplicativo modifica apenas uma pequena quantidade de dados em uma exibição enquanto exibe uma grande quantidade de dados mistos.

verdadeiro. O changelog de contexto pode ser muito poderoso quando usado de forma dinâmica.

mas também é muito avançado. Eu tenho um snippet para passar por todas as alterações em um contexto, atribuir os dados à variável apropriada na classe assistance (campo na estrutura ou campo em uma linha em uma tabela interna) e chamar dinamicamente um método manipulador (se houver). Eu compartilhei esse trecho com muitos desenvolvedores altamente qualificados. Até o momento, apenas 2 realmente entendiam o que faziam e eram capazes de aplicá-lo em seus próprios componentes.

as regras que você menciona são interessantes o suficiente, mas como Steve mencionou, você pode querer elaborar sobre o propósito e a ideia subjacente.

saúde!