Necessito de seu auxílio.

Como utilizar o BO para controlar processamento em tabelas estrangeiras? Por exemplo: A adição/alteração/exclusão de um registro na tabela "C" afetará o campo "Contador" na tabela "A". Um caso típico é a inclusão/alteração/exclusão de um item em um lote de saída com atualização dinâmica do saldo de estoque na tabela produto.

Situações possíveis:

a) Inclusão de item de saída em um lote subtrai a qtde do saldo da tabela produto a partir do relacionamento "ItensSaida.IdProduto <-> TbProduto.IdProduto".

b) Exclusão do registro de item de saída, adiciona (devolve) a qtde ao saldo da tabela produto, considerando o mesmo relacionamento.

c) Alterações no item de saída provocariam duas operações: 1) Adiciona(devolve) a 'qtde original' ao saldo da tabela produto, considerando o 'IdProduto original' e subtrai a 'qtde atual' da tabela produto tomando como chave o 'IdProduto atual' (que poderá ou não ter sido alterado).

Enfim... Pensei em montar isso diretamente na classe do BO levando em consideração os eventos AfterSave, BeforeSave, etc. No entanto, como o BO pode salvar várias 'rows' ao mesmo tempo não estou conseguindo encontrar a maneira de implementar essa regra diretamente na classe. Na verdade estou tentando aí substituir eventos de 'disparador' que normalmente configuro no SQL Server. Acredito que no BO eu teria mais controle, caso necessitasse alterar a regra e criar outras condições de análise (até porque o DDT do StrataFrame ainda não oferece recursos para configuração de Triggers 'disparadores').

Bom, você que já tem uma vasta experiência com a ferramenta, poderia me ajudar a 'poupar o tempo' de pesquisa ?!!! 

Abraços...

Este tópico está relacionado com o que deixei para Trent analisar: http://forum.strataframe.net/Topic16570-7-1.aspx

Com o seu bom inglês acho que poderemos encontrar uma resposta para a questão.

Observei que os eventos de BO BeforeSave, AfterSave, BeforeDelete e AfterDelete reagem de forma distinta quando estão agregados ao Form Principal ou quando estão relacionados como filhos de um BO principal.

Considerando a questão do 'processamento direto/inverso' em tabelas relacionadas você ou Trent teriam um exemplo de implementação de código com as características elencadas neste tópico (post inicial) ?

Você pode sempre forçar um Save individual em alguma ação no seu ChildDialog, e isto irá sempre executar um AfterSave. Neste ponto você pode ir ao banco de dados e alterar o conteúdo de sua tabela pai. É isto que está querendo dizer?

Na realidade não gostaria de ficar dependente de ações no form de edição, pois são regras que pertencem à própria natureza do registro e assim ficariam mais seguras se estivessem implementadas diretamente no BO (regra de negócio e camada de persistência).

Pelo que pude verificar o correto seria o BO ter os eventos (Before/After) também implementados para o row e não apenas para o próprio BO. Os eventos Before proporcionariam a opção de cancelamento e os eventos After trariam uma versão do DataRow com o status de ação ajustado antes da efetivação do update no banco de dados. Isso possibilitaria a execução das ações de lançamento direto/inverso em bases relacionadas. Nem sempre um lançamento filho refletirá uma alteração no campo da tabela pai. Às vezes o lançamento/processamento precisa também ser executado em uma outra tabela referenciada.

Pense, por exemplo, em uma tabela de títulos com um campo 'StatusTitulo' que aceita 1-Liberado e 2-Vendido. Quando o título fosse vendido (inclusão de um registro na tabela de venda de títulos) o StatusTitulo seria alterado para 2. No entanto, se a venda for cancelada o StatusTitulo deve voltar para a condição anterior. Esse é um caso típico de processamento direto/inverso. Essa regra de processamento no campo StatusTitulo estaria configurada nos eventos AfterSave (row) da tabela de venda do título. Sendo uma regra incondicional (sempre acontecerá), seria correto codificá-la na camada que antecede a persistência dos dados (o BO). Ou seja, se o BO fosse referenciado em vários Forms (para contemplar modelos diferentes de venda do título) a regra de alteração do StatusTitulo seria herdada.

Utilizo desde 1997 a ferramenta GAS (atualmente na versão GAS2007) que configura processos e lançamentos direto/inverso no form de edição.

Uma outra maneira de garantir esse tipo de regra seria criar os triggers no banco de dados. No entanto o DDT não disponibiliza recursos para isso (teria que criar uma classe que gerasse os scripts no banco de dados).

Fica aí levantada a questão...