Se você responder sim a pelo menos uma dessas perguntas, então é melhor passar a event handlers nas suas customizações o quanto antes!
- Você está tendo dificuldade em instalar hotfixe após hotfix, CU após CU?
- Será que a migração do código consome mais tempo do que você desejava inicialmente?
- As customizações estão feitas de tal forma que cada atualização requer merges cada vez mais complicados, de tal forma que o desenvolvedor fica perdido tentando descobrir qual o código vai para onde?
Se utilizado corretamente, event handlers tem o potencial de reduzir muito o tempo gasto em upgrades de código.
Caso você nunca tenha ouvido falar, existe um white paper que explica o uso de delegates e event handlers aqui e no MSDN aqui.
Contudo, a ideia é simples: ao minimizar o código em objetos de core (ou sys), você pode fazer o processo de upgrade de código de maneira muito mais fácil por que toda a lógica de negócios esta agrupada em novos métodos em novos objetos ou métodos no próprio objecto que necessita de customização e não causa ‘overlayering’ nos métodos originais.
Para minimizar o impacto das customizações a ideia é a seguinte: Uma determinada customização me obriga a alterar o método updateOrderBalances da classe TradeTotals, ao invés de entrar no método e fazer as mudanças necessárias, eu adiciono um POST event handler ao método updateOrderBalances que chama o método estático postUpdateOrderBalancesHandler_BR na mesma classe.
Por uma decisão de implementação, eu quis colocar minha customização em um método private na mesma classe (postUpdateOrderBalancesBR), separando assim a real lógica de negócio da chamada do event handler.
Event handlers podem ser usados em:
- Métodos de classe
- Métodos estáticos de classe
- Métodos de tabelas
- Métodos estáticos de tabela
Event handlers em classes
Adicionar 2 métodos na mesma classe: O event handler é chamado pelo infraestrutura e tem uma chamada para o segundo método, chamado pre/post method que contei a regra de negócio, esse método deve ser private.
Quando o método original retornar algum valor, o pre/post method deve por padrão deve retornar o valor original.
Prós:
- Clara separação de infraestrutura e regra de negócio
- Acesso a variáveis de classe
- Event handler pode ser gerados automaticamente por um editor script
Convenção de nome para event handler: <”pre” | “post”><method name>EventHandler
Convenção de nome para pre/post method: <”pre” | “post”><method name>
Event handlers em tabelas
Adicionar uma nova classe que será utilizada para chamar o event handler, e então seguir os guidelines para classes.
Convenção de nome para classe: <associated table name>EventHandler
Quando usar?
Não é sempre que podemos usar event handlers, veja as dicas a seguir:
Não candidatos:
- Código dentro de loops
- Código que usa ou muda variáveis do método
Candidatos:
- Código adicionado no começo do método
- Código adicionado no fim do método
Fortes candidatos:
- ModifiedField
- ValidateField
- Métodos InitFrom*
Deve ser usado com cautela:
- Código adicionados dentro de clausulas IF, você pode copiar o if para dentro do pre/post method
- Códigos entre ttsBegin/ttsCommit quando o método é publico
- Métodos Display – pode haver uma queda de performance na UI
