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:
public class Usuario implements Serializable {
private String nome;
private Endereco endereco;
private List livros;
// etc...
// get / set
}
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:
public class UsuarioBO extends Usuario {
/*
* Implementacao dos metodos de negocio
*/
}
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.
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.
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 existe necessidade em criar uma classe Usuario, nesse caso. Voce pode fazer:
public interface User implements Serializable {
// getters, setters, enums, e o que mais
}
E depois:
public interface UserBusiness extends User {
// metodos de negocio
}
E depois…
public class UserImpl implements UserBusiness {
// implementacao de tudo
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
