BEF: Permitir evolução gradual dos sistemas para C# sem gerar dívidas técnicas
A diretiva da empresa é escrever qualquer novo recurso em C# com BEF.
Entretanto, sempre existiu uma dificuldade no BEF e atualmente qualquer tentativa de contorno acaba gerando uma dívida técnica.
Cenário:
* É extremamente comum que qualquer componente de negócio manipule várias entidades.
* Também é extremamente comum encontrar tabelas nos sistemas com regra de negócio em VBA.
* Ao manipular estas tabelas a partir do BEF as macros são ignoradas.
A reescrita/conversão do VBA para BEF não é possível pois envolve Macros de várias camadas.
A conversão de macros com alguma frequência exige refatoração de objetos Delphi, que ainda esperam como parâmetro o BSistema, que não existe no BEF.
A refatoração de objetos Delphi não é algo trivial, pois envolve outras camadas e envolve ajustes em códigos que acionam o objeto.
Além disso, é possível que existam chamadas em BEF pressupondo que a Macro está executando quando não está.
Qualquer tentativa de contorno é feia e frágil como duplicar código, e outras que prefiro nem mencionar.
Ou seja atualmente o desenvolvedor do sistema não consegue atender a diretiva da empresa sem gerar uma dívida técnica.
A sugestão é que o BEF facilite o acionamento do VBA, mesmo que seja através de algo explícito como alguma variavel de contexto ou comando.
-
Comentário de Juliano Pezzini
Pq não usar PhysicalQuery ??