Dicas de modelagem de JavaBeans para otimizar o desenvolvimento de suas aplicações WebDynpro

Antecedentes

Antes de entrar em detalhes nesta publicação, responda várias perguntas consigo mesmo.

1. Você se sente confortável com os nós de valor?
2. Não ignore a pergunta [1]. Realmente, tente contar os cliques necessários para vincular um modelo RFC adaptativo com o número de operações irritantes para criar nós de valor da mesma estrutura em vários controladores desconectados.
3. Você está usando atributos calculados? Já sentiu que a partir do terceiro ou quarto atributo calculado está quebrando os princípios de OO e o código do controlador está ficando volumoso?
4. Quantas vezes você tenta fazer um mapeamento de contexto extraordinário entre nós de valor? E sente que está tentando se encaixar nas restrições de mapeamento de contexto em vez de implementar a funcionalidade principal?
5. Já teve dificuldades para expressar restrições de validação complexas? Mesmo tão óbvias (suspiro) como correspondência de expressões regulares? Ou realmente complexas como verificação de ISBN?
6. Já achou que as APIs do WebDynpro relacionadas ao contexto são bastante limitadas? Sem suporte para eventos de mudança de atributo, regras de invalidação arcanas e inconvenientes, etc.

Se respondeu pelo menos algumas das perguntas com "Sim, acontece comigo", então esta publicação é definitivamente para você. Caso contrário: Quem sabe, talvez "volte" mais tarde. De qualquer forma, desaconselho veementemente que aplique as técnicas mencionadas abaixo se não houver tais problemas em seu desenvolvimento atual. Não introduza complexidade apenas porque acha que alguma técnica é legal. Mas "se": então:, bem, a toda velocidade ?

Isenção de responsabilidade / Garantia / Notas importantes

Primeiro, algumas das técnicas mencionadas (validação / restrições de propriedade) dependem de certo comportamento do WebDynpro. Realmente não tenho ideia se é padrão ou não. Provavelmente, os moderadores serão bastante pacíficos e não excluirão a publicação imediatamente após ler esta linha ou me culparão por soluções não padrão. Suponho que a funcionalidade existente até o momento é muito importante, e se houver problemas de compatibilidade, é possível discuti-los nos comentários.

Segundo, desenvolvi meu código usando NW04s ou Paris (sim, sou definitivamente um sortudo ;). Fiz o máximo para não quebrar a compatibilidade com versões anteriores. Mas se tiver algum problema ao retroceder para SP11+, podemos discutir os problemas também nos comentários.

Terceiro ("por último"), não tentarei descrever como programar JavaBeans; o site relacionado Java tem informações suficientes, assim como os JavaDocs incluídos com o NetWeaver.

Caso de uso

Imagine que temos que desenvolver um componente para editar uma equipe de funcionários. Digamos que precisamos criar um editor para o pessoal de um projeto. Inicialmente, o editor é pré-inicializado por uma certa equipe de usuários de uma parte externa como um motor sofisticado de alocação de pessoal (apenas estamos emulando). O usuário pode adicionar / remover funcionários da equipe, bem como editar propriedades dos existentes (deixamos a magia do UME fora deste exemplo). Enquanto o editor oferece uma grande flexibilidade ao usuário final, impõe uma restrição importante: a variação do salário total da equipe não deve exceder certo percentual do salário inicial da equipe. O usuário deve receber um feedback imediato sobre essa violação da restrição. Além disso, ao sair do editor, precisamos informar o componente externo sobre as alterações delta na equipe: o editor deve fornecer informações precisas sobre:

1. funcionários atualizados da lista original
2. funcionários removidos da lista original
3. funcionários recém-adicionados

Sem mais delongas, vamos começar com a implementação.

Modelagem de JavaBeans

Primeiro, criaremos (quase) JavaBeans regulares para nosso caso de uso. Aqui discutirei o resultado final, no entanto, na verdade é o resultado de várias tentativas e refatorações.

Bem, temos que definir nosso Employee JavaBean. É apenas uma classe Java regular com métodos de acesso/mutador de propriedades correspondentes. Aliás, se estiver desenvolvendo seus JavaBeans do zero, recomendo o seguinte caminho:

1. Criar classe com campos privados para propriedades.
2. Utilizar a opção Gerar Getter / Setter de Source / Eclipse para gerar métodos de acesso / mutador.
3. Ajustar os tipos de retorno dos métodos se diferirem do tipo de campo. Em nosso caso, a propriedade birthDate