Arquivo Discussoes de Programacao e Tecnologia Bom dia!
Eu estou com uma dúvida que é a seguinte, é “errado” ou não é uma boa prática buscar informações de um objeto no banco no momento em que o objeto é construido?
Exemplo:
public class Cliente{
public Cliente(){
}
public Cliente(int codCliente){
//Busca no banco as informações do cliente e preenche as propriedades
}
}
Amigão, não é uma boa prática você realizar esse tipo de procedimento. O melhor seria você criar um método que realize a busca da informação que você precisa.
Você pode criar uma factory que faça isso pra você. Em Rails, existe o create, que faz parte do ActiveRecord e faz algo parecido com isso, salvando as informações diretamente no banco. Já se você usar o new, ele apenas cria um objeto sem os dados. E o find faz exatamente o que você quer. Você pode fazer isso em Java mas acho melhor você ter um Repository para carregar seu objeto.
E ae, blz!
Entaum, fikei com algumas dúvidas.
Q conceito é esse de Factory?
Repository?
E ah, eu implementando em .NET
E ae, blz!Entaum, fikei com algumas dúvidas.
Q conceito é esse de Factory?
Repository?E ah, eu implementando em .NET
O que é Factory.
O que é Repository.
São dois padrões de projeto e podem ser utilizados em DotNet.
ps. Na próxima poste no forum “Outras Linguagens” e especifique a mesma para facilitar. 
E ae!
Blz pode deixa!
Mas agora eu fikei em dúvida onde esses conceitos se encaixam no meu problema.
Eu to lendo, lendo mas ainda ta meio abstrato pra mim.
E ae!
Blz pode deixa!Mas agora eu fikei em dúvida onde esses conceitos se encaixam no meu problema.
Eu to lendo, lendo mas ainda ta meio abstrato pra mim.
Repare só:
Você tem uma classe chamada Cliente pelo nome dela imagino que seja uma classe de seu domínio (o que mais interessa no seu sistema). A persistência faz parte da infra-estrutura de sua aplicação, logo não deve ser misturada ao seu domínio, no momento que você coloca dentro de sua classe Cliente a chamada para criar a conexão de banco de dados o seu dominio tá “sujo”, entendeu? Onde entra os padrões? Os padrões nos ajudam a implementar nosso software de maneira a não comenter esse tipo de erro. O pessoal sugeriu Repository por que seria numa classe que não Cliente a resposável por “fornecer” os objetos clientes que você precisa. O padrão Factory foi sugerido para que você não cria conexões diretamente em suas classes, mas sim crie uma classe que tenha um método que gera essas conexões para você (Factory é usado também para para criar outras coisas, só tou me pretendo no exemplo). É necessário um pouco de tempo para entender tanta coisa, conselho: Continue estudando os padrões sugeridos e outros mais antes de sair implementando de qualquer maneira…em breve vai saber por quê! (as manutenções futuras é que o digam).
Ah tah, acho q entendi!
Eu ja tinha ouvido falar nisso!
Ai eu fiz assim:
Eu criei duas bibliotecas de classes, uma soh com o Modelo e outra soh com os acessos ao banco.
Ai fico uma coisa tipo assim:
//Classe de persistencia
public class Cliente{
public static void insert(parêmtros){
//Conecta e executa no o SQL no banco
}
}
//Classe do modelo
public class Cliente{
public void salvar(){
Persistencia.Cliente.insert(Propriedades Ciente)
}
}
Eu to fazendo assim, naum faço idéia se isso é uma boa maneira ou não.
Oi,
Não endendi direito…tem duas classes com o nome “Cliente”…mas pelo formato tá parecendo outro Padrão: ActiveRecord, pesquise sobre ele, não é muito recomendado por grande parte de comunidade aqui do GUJ, mas vale a pena sempre conhecer as coisas. Acredito que deva pesquisar mais sobre os padrões até conseguir imprimir no código os conceitos com correção.
Leitura Obrigatória: Padrões de Projeto do GoF.
Blz, Vlw!
Vou dar uma pesquisada.
Mas entaum, saum duas classes clientes pq cada uma fica em uma biblioteca diferente.
Blz, Vlw!
Vou dar uma pesquisada.Mas entaum, saum duas classes clientes pq cada uma fica em uma biblioteca diferente.
Dê nomes mais “eficientes” a suas classes, uma classe que vai persistir objetos não pode ter esse nome…é estranho e vai confundir outras pessoas e até mesmo você.
ps. também não gosto de nomes de classe com prefixo ou sufixo com o nome de algum padrão, exemplo: ClienteDAO, FornecedorBO, RepositoryPedido…mas entre essa escolha e a sua, prefiro essa!
@carrijo
Você não precisa de 2 classes cliente. Você pode ter um RepositorioCliente que é o carinha que representa onde ficam armazenados os clientes.
Blz entaum! Vou ler o livro e ver oq acontece!
Vlw