Construtor e acesso a banco

Programação Arquitetura
#1

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

}

}
#2

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.

#3

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.

#4

E ae, blz!

Entaum, fikei com algumas dúvidas.
Q conceito é esse de Factory?
Repository?

E ah, eu implementando em .NET

#5

[quote=carrijo]E ae, blz!

Entaum, fikei com algumas dúvidas.
Q conceito é esse de Factory?
Repository?

E ah, eu implementando em .NET
[/quote]

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. :wink:

#6

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.

#7

[quote=carrijo]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.[/quote]

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).

#8

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.

#9

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.

#10

Blz, Vlw!
Vou dar uma pesquisada.

Mas entaum, saum duas classes clientes pq cada uma fica em uma biblioteca diferente.

#11

[quote=carrijo]Blz, Vlw!
Vou dar uma pesquisada.

Mas entaum, saum duas classes clientes pq cada uma fica em uma biblioteca diferente.[/quote]

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!

#12

@carrijo
Você não precisa de 2 classes cliente. Você pode ter um RepositorioCliente que é o carinha que representa onde ficam armazenados os clientes.

#13

Blz entaum! Vou ler o livro e ver oq acontece!

Vlw

#14