Nao concordo… acho que os sufixos dao uma visualização melhor do que é cada classe, sua camada… estamos falando aqui de MVC claro…
Qual seria sua sugestão, Adolfo? É melhor que os nomes das classes nao tenham sufixos?
Nao concordo… acho que os sufixos dao uma visualização melhor do que é cada classe, sua camada… estamos falando aqui de MVC claro…
Qual seria sua sugestão, Adolfo? É melhor que os nomes das classes nao tenham sufixos?[/quote]
Qual a diferença entre sufixos em classes e packages com nomes significativos além de economia em redundância?
Imagina isso se repetindo numa aplicação com mil classes… com mtas linhas de codigo… toda hora q eu precisar de um VO Usuario, preciso chamar br.com.minhaempresa.minhaplicacao.vo.Usuario :shock:
Com sufixos vc intuitivamente sabe que aquele objeto é um VO e o outro um DAO… e nao precisa poluir seu codigo com o caminho completo da classe…
E alem dos sufixos defendo a separação em pacotes tambem… sempre!!!
Imagina isso se repetindo numa aplicação com mil classes… com mtas linhas de codigo… toda hora q eu precisar de um VO Usuario, preciso chamar br.com.minhaempresa.minhaplicacao.vo.Usuario :shock:
Com sufixos vc intuitivamente sabe que aquele objeto é um VO e o outro um DAO… e nao precisa poluir seu codigo com o caminho completo da classe…
E alem dos sufixos defendo a separação em pacotes tambem… sempre!!![/quote]
Antes de tudo, se você estiver usando VO em sua aplicação é sinal que tem algo errado, não vou entrar em detalhes, porém você pode encontrar mais informações neste tópico:
Uma modelagem mais detalhada pode resolver este problema, por exemplo:
Não é uma boa ideia colocar tudo que está relacionado “as tabelas” de um negocio relacionado a cadastro de usuário em um simples DAO chamado Usuario, algo mais sensato seria a divisão destas classes em mapeamentos as tabelas reais, por exemplo:
br.com.minhaempresa.minhaplicacao.negocio.usuario.Usuario; // classe de negocio
br.com.minhaempresa.minhaplicacao.persistencia.usuario.Login; // trata o acesso aos dados da tabela login
br.com.minhaempresa.minhaplicacao.persistencia.usuario.Cadastro; // trata os dados relacionados a tabela de cadastro
br.com.minhaempresa.minhaplicacao.persistencia.usuario.Complemento; // trata os dados relacionados a tabela de complemento de informaçõs.
De qualquer forma, não vejo a nomenclatura de classes como algo que deve ser forçado aos desenvolvedores, e sim algo que deve ser discutido nas equipes até que se crie um ponto de equilibrio.