EJB Business Logic

Outro exemplo de lógica de negócio usando EJB (Entity Beans + Façades) que eu desejaria aplicar:
Ao adicionar um item em um orçamento atualizar o valor total do orçamento.

Parece bobo mas essas implementações simples eu não encontro exemplos. Quando eu pesquiso sobre validações e lógicas de negócios usando EJB na Web vem muito lixo, muita coisa repetitiva explicando o básico e nada que eu possa aproveitar.

EJB é um framework, e assim como qualquer outro framework ele não tem nenhum tipo de modo ou manual de como implementar a lógica.

O jeito correto é estudar patterns relacionados ao seu problema. Ler o livro do GoF ou Head First Oriented Object and Analisys pattern.

Você poderia muito bem fazer algo como PessoaValidator.validate(pessoa) ou um método que fosse validarPessoa(pessoa) ou validarPessoa(regras, pessoa).

Poderia também deixar todas essas regras em um service/facade da vida e sempre invocar esse cara para validar o objeto: pessoaFacade.validate(pessa).

Enfim, ñ existe uma resposta pronto e nem framework que te dirá como criar suas regras de negócio. Isso vai do seu conhecimento de OO e Patterns aplicados ao seu Framework.

Obrigado por sua resposta Hebert.

De forma a dar continuidade na implementação do meu projeto optei por aplicar validação de restrições aos meus Entity Beans e suas propriedades usando Bean Validation JSR-303 ([google]jpa constraint validation[/google]) e métodos com regras de negócio nos Beans de Fachada.

Só se lembre de uma coisa, se você fizer a validação apenas na fachada e um método que depende dos dados em outro EJB for chamado, você pode ter erro de lógica/processamento.

View01 ----> fachada01 (aqui valida) ----> EJB01 (fará processamento)

Imagine que EJB01 se depender de um email correto, por exemplo.

Caso uma alteração como abaixo seja feita:
View02 ----> fachada02 ----> EJB02 ----> EJB01 (fará processamento)
Note que a validação feita na fachada01 não será realizada, pois até o momento da chamada não sabia-se que tal informação precisaria de validação.

As validações do lado do negócio devem ficar sempre próximas de onde são utilizadas.

Por favor, me diga então se esse é o procedimento correto.

• Estou adicionando constraints e custom constraints às propriedades do meu JPA.
• Para o manejo das propriedades antes e depois dos eventos de persist, merge e remove estou utilizando os respectivos métodos pre/postCreate, pre/postUpdate e pre/postRemove.

Assim, acredito que independentemente da fachada que manipule a entidade, deverá obrigatoriamente passar pelo meu código.

Desculpe, onde eu escrevi JPA eu quis dizer Entity Bean.

robinson_rk:

Assim, acredito que independentemente da fachada que manipule a entidade, deverá obrigatoriamente passar pelo meu código.

Olha, já estou tendo problemas com essa estrutura.

Nas restrições customizadas só é possível fazer validações de um nível muito simples. Não consigo, por exemplo, saber se a validação está sendo feita durante um Create ou um Update (durante o Delete nem passa). Não consigo me basear nos valores anteriores à alteração que está sendo feita. Também não consigo validar valores dos campos contra o resultado de um método de uma Fachada pois de toda a forma que eu tento instanciar um Bean de Fachada dentro de uma constraint validation ocorre erro em tempo de execução.

Acabei descartando as restrições customizadas para passar a usar os Callback Methods. Com eles eu consigo saber qual a operação que está sendo feita pois o método executado é diferente (postLoad, prePersist, postPersist, preUpdate, postUpdate, preRemove e postRemove). Também consigo me basear nos valores anteriores criando uma cópia local do registro corrente a cada postLoad, assim quando um Create, Update ou Delete for executado eu tenho uma cópia do registro anterior (prevejo problemas de performance). Porém, dentro dos Beans de Entidade eu também não estou conseguindo instanciar Beans de Fachada para utilizar seus métodos de negócio.

Se não for possível instanciar um Bean de Fachada em um Bean de Entidade essa estrutura se tornará inútil e terei que voltar a utilizar apenas métodos nos Beans de Fachada para todas as operações.

Como faço para resolver esse problema?

Bom, vamos lá.

Como já foi dito aqui tudo depende. Como você modelou sua aplicação?

Você tem classes de negócio? classes com o nome *Business ou *Service ou coisas do tipo? Se sim, é ali onde devem ficar suas validações de negócio.
O método PrePersist você pode usar para validar se os dados obrigatórios da entidade estão preenchidos, ou montar uma PK composta antes da persistência, coisas desse tipo.

Agora se sua aplicação foi desenvolvida seguindo o DDD, a validação fica na classe de domínio.

Finalmente! Demos uma volta gigante mas chegamos onde eu queria que é a resposta para a minha dúvida descrita lá no início. Gostaria de uma indicação de material que explique esses modelos de desenvolvimento para que eu entenda e possa escolher entre eles o melhor para o meu caso.

Você poderia me indicar algum material que me ajude a implementar minhas regras de negócio da maneira mais adequada?

Leia os livros de Design Patterns que o Hébert sugeriu. E leia também o livro sobre DDD do Eric Evans