Qual o Design Pattern?

estava esquecendo dessa camada tb :

public class CadastroBean {	


	private HtmlInputText loginComponente;
	private String login="";
	private String senha="";
	private String mail="";	
	private int idParaRemocao; 	
	private ServiceLocator service;	
	private List usuariosCadastrados = new ArrayList();	





	public String cadastraUsuarioAction(){
		setLogin((String) getLoginComponente().getValue());
		service.getPersistentService().save(createUsuarioBussiness());	
		return DCContants.PAGINA_CADASTRO;
	}	





	public void removeUsuarioAction(ActionEvent event){
		HtmlCommandLink link = (HtmlCommandLink) event.getSource();
		getService().getPersistentService().remove( ((Integer)link.getValue()).toString() );		
	}	





    /**
     * cria um usuario do model
     * @return usuario, o usuário criado com os dados do form
     */
    public Usuario createUsuarioBussiness(){
         //TODO usar uma factory, tirar os printStackTrace
         Usuario u = new Usuario();
         try {
            BeanUtils.copyProperties(u, this);
         } catch (IllegalAccessException e) {  
            e.printStackTrace();
     	 } catch (InvocationTargetException e) {
             e.printStackTrace();
         }
       	 reset();
         return u ;
    }    





	public void reset() {
	        setLoginComponente(new HtmlInputText());
	        setMail("");
        	setSenha("");
	}	





	public HtmlInputText getLoginComponente() {
		return loginComponente;
	}





	public void setLoginComponente(HtmlInputText loginComponente) {
		this.loginComponente = loginComponente;
	}





	public String getLogin() {
		return login;
	}






	public void setLogin(String login) {
		this.login = login;
	}





	public String getMail() {
		return mail;
	}





	public void setMail(String mail) {
		this.mail = mail;
	}





	public String getSenha() {
		return senha;
	}





	public void setSenha(String senha) {
		this.senha = senha;
	}





	public List getUsuariosCadastrados() {
		usuariosCadastrados = service.getPersistentService().selectTodos();
		return usuariosCadastrados;
	}





	public void setUsuariosCadastrados(List usuariosCadastrados) {
		this.usuariosCadastrados = usuariosCadastrados;
	}




	
	public ServiceLocator getService() {
		return service;
	}





	public void setService(ServiceLocator service) {
		this.service = service;
	}




}

Porcamente implementado em MVC, ou pelo menos tentaram… eu sugeriria colocar sufixos VO, DAO, BO, etc, nos nomes das classes, isso soh pra comecar…

Pra ficar mais porco ainda?

Pra ficar mais porco ainda?

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?

É melhor não usar BO, VO, etc… Procurem aqui no GUJ que já rolou uma discussão sobre isso. E está rolando de novo agora

Pra ficar mais porco ainda?

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?

Qual a diferença entre sufixos em classes e packages com nomes significativos além de economia em redundância?

aleck:

Qual a diferença entre sufixos em classes e packages com nomes significativos além de economia em redundância?

Ja tive problemas com classes com nomes iguais em pacotes diferentes…

br.com.minhaempresa.minhaplicacao.vo.Usuario vo;
br.com.minhaempresa.minhaplicacao.dao.Usuario dao;

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!!!

andre2k2:

aleck:

Qual a diferença entre sufixos em classes e packages com nomes significativos além de economia em redundância?

Ja tive problemas com classes com nomes iguais em pacotes diferentes…

br.com.minhaempresa.minhaplicacao.vo.Usuario vo;
br.com.minhaempresa.minhaplicacao.dao.Usuario dao;

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!!!

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:

http://www.guj.com.br/posts/list/81232.java

Voltando ao 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.

[]'s

Obrigado pelo retorno,

mas gostaria de saber qual o Design Pattern usado ???

sei que é MVC mas teria um especifico que foi usado…

abs