Eu procurei em vários fóruns e afins e não encontrei nada a respeito.
A minha pergunta é:
Pq fazer herança em session bean ? Mais imoprtante ainda, a especificação permite ? Se permite, qual é a desculpa ?
Sei lá, não fecho utilizade em um session bean herdar as caracteristicas de outro session bean…para mim um session bean é como se fosse uma ferramenta, que eu utilizo e nada mais…
Sim, desde que você não coloque regras de negócio no seu SessionBean não deveria ter muitos motivos para usar herança, exceto reaproveitar métodos, o que você pode fazer com agregação a maior parte do tempo.
mcampelo
Não deveria ser o contrário?
Se eu tenho regra de negócio no meu Session, não uso herança.
Se não tenho regra de negócio no meu Session, uso herança.
(Na verdade não estou muito certo se herança em Session é algo válido. Mas fiquei meio confuso com o que você escreveu sobre as regras de negócio)
[]'s
Marco Campêlo
pcalcado
Eu estou falando de herança de Session Beans, um SB extende outro.
Se você não colocar regras de negócio num Session bean, provavelmente ele vai ser só um façade com métodos que chama os objetos de domínio para fazer o trabalho sujo. Se estes métodos estão complexos a pontod e haver uma hierarquia de session beans, talvez com um template method, é possível que exista muita regra de negócio no seu session bean.
É claro que eu estou falando de um mundo hipotético onde as pessoas são felizes e não colocam regras de negócio nos EJBs… Geralmente o que eu vejo como herança são métodos que recuperar objetos como loggers ou conexões do SGBD.
A tendência nesses casos é utilizar Session Beans como Commands, o que costuma causar um lindo design procedural num sistema.
Já li um documento de um consultor pago em euros dizendo que a melhor forma de reusabilidade era oferecida por essa solução, “methods can easily be reused by copying, pasting and modifying existing methods”.