Solucao para evitar o uso de VOs

Debugger Membro desde: 07/09/2003 22:34:36 Mensagens: 65 Offline

Bom dia,

Tenho andado pesquisado sobre o uso ou nao de VOs e percebi que nao eh muito legal usa-los, devido a varios motivos. Por exemplo, se eu atualizar minhas entitys com novos atributos, vou ter que sair alterando todos os meus VOs.

Uma solucao seria criar a minha entity e uma outra classe que extenderia essa entity (que ai sim teria os metodos de negocio). Algo assim:

A classe acima seria a classe q eu enviaria pro cliente.

e a classe que de fato possui os metodos de negocio seria algo como a classe abaixo:

Resumindo,

- Meus controladores iriam usar a classe UsuarioBO.
- Seria enviado para o cliente apenas a classe Usuario

Dessa forma, caso houver alteracoes ou inclusoes de atributos ou qqer coisa do genero, eu so iria modificar em um lugar so, alem eh claro de diminuir o numero de classes do meu sistema.

O que vcs acham?

Valeu,
Marcos

C nao me engano, embora vc tenha a interface Usuario, para trafegar, vc necessitara da Instancia de um objeto q implemente a mesma tipo:

Neste caso, vc estaria passando o UsuarioBO da mesma maneira...

Isto eh soh um palpite, me corrijam c eu estiver errado

Debugger Membro desde: 07/09/2003 22:34:36 Mensagens: 65 Offline

Usuario eh uma CLASSE CONCRETA com gets / sets. Nao eh uma interface

Ops! Nao prestei atencao

E pra que vc precisa de uma classe concreta, nesse caso? Uma interface tambem resolve. Voce pode ter duas ou mais interfaces implementadas pelo mesmo objeto de negocios, so tomando o cuidado de nao colocar comportamento demais numa classe so.

De resto, concordo com voce, quanto menos DTOs e VOs e objetos burros, melhor.

Debugger Membro desde: 07/09/2003 22:34:36 Mensagens: 65 Offline

CV,

nao entendi seu post. Mas a minha intencao em "quebrar" a classe Usuario em 2 (Usuario e UsuarioBO) é de poder enviar pro cliente uma classe (Usuario) que funcionaria exatamente como um VO.

A vantagem eh q eu nao iria ficar criando um VO pra cada entidade minha q eu precisar enviar seus respectivos dados pro cliente.

Nao sei se consegui me explicar,

Valeu
Marcos

Nao existe necessidade em criar uma classe Usuario, nesse caso. Voce pode fazer:

E depois:

E depois...

Pra parte "burra" do sistema, voce passa uma referencia a um User (que nao ve os metodos de negocio), e pras partes onde mexer com o negocio eh necessario, passe um UserBusiness. Desse jeito voce NUNCA, JAMAIS precisa passar um UserImpl pra ninguem

Isso não passa na compilação...
Cv, uma interface não pode implementar outra interface!Ela pode dar um extends em outra interface!

Ah, Ironlynx, da um desconto... eh natal

Notícias, artigos e o maior fórum brasileiro sobre Java