Aquiterura 3 camadas novamente

twwwister seguinte,

quando tu trazer o ResultSet do banco tu popula teus bean com os valores e cria uma Collection deles e passa pra cima, pra camada que for tratar isso!

era isso?

Bom na verdade sim… eu to fazendo assim (não sei se está correto mas…):
Dentro das classes Entidade(as representantes de tabelas) pra cada atributo eu criei um array, aí quando eu instancio a classe ela preenche os arrays de seus atributos com os valores do BD. Não sei mas acho que não é o correto de se fazer… mas vamos tentando hehe!

Valeu se mais alguém puder ajudar!!! :lol:

nao cara. nao faz isso, é muito feio!
ehehe

teus beans (essas classes que representao tabelas no BD) deve representar UM E SOMENTE um registro da tabela.
entao os atributos nao serao array!

quando tu fizer a consulta que retornar varios registros do banco voce vai instanciar varios beans e coloca-los em uma Collection e passa a collection para poder entao tratar eles mais na frente.

mais ou menos assim:

public listarClientes()
{
. ResultSet rs = null
. (conexao e consulta)
. 

rs = preparedStatemend.executeQuery();

  Collection clientes = new java.util.ArrayList();

  while( rs.next() )
  {
    Cliente c = new Cliente( rs.getInt(cod_cliente),     rs.getString(nome_cliente) );
    clientes.add(c);
  }

  return clientes;

}

sacou?
flw

hmmm soh… bom vamo ve se eu me viro assim… pior que ja to implementando com a minha soluçaum! aiaiaaaaaa 8O

Olá,

VOu supor que voce quer fazer algo OO.

Num modelo OO, você nao deve ter dados separados de “inteligência”, isso quer dizer algumas cosias:

1 - Seu banco de dados deve se moldar aos seus objetos, não seus objetos se moldarem ao banco de dados

2 - Não crie classes que espelham tabelas, faça com que as classes nem imaginem que existam tabelas, bancos de dados ou nada além de sua responsabilidade

3 - Suas “classes de inteligência” devem ser as mesmas classes de entidades, que não encessariamente vão ser javabeans

“pcalcado”:

Olá,

VOu supor que voce quer fazer algo OO.

Num modelo OO, você nao deve ter dados separados de “inteligência”, isso quer dizer algumas cosias:

1 - Seu banco de dados deve se moldar aos seus objetos, não seus objetos se moldarem ao banco de dados

2 - Não crie classes que espelham tabelas, faça com que as classes nem imaginem que existam tabelas, bancos de dados ou nada além de sua responsabilidade

3 - Suas “classes de inteligência” devem ser as mesmas classes de entidades, que não encessariamente vão ser javabeans

entao uma duvida pcalcado,

vamos imaginar uma classe cliente, ok?
ela deve ou nao ter o atributo codigo?
pq quando faço minhas classes eu coloco esse atributo mas pensando na tabela do banco.

e outra coisa…
tava fazendo um DAO e no metodo createCliente(string, nome, string endereco, …) que é o metodo que da o INSERT no banco eu passo nao um cliente, pq até o momento eu ainda nao tenho seu CODIGO. entao passo todos os outros atributos e depois do insert, quando eu já tenho um codigo (imaginando q o campo codigo seja auto-incremento) daih eu populo um cliente e retorno ele pra controller.

o processo é esse mesmo ou esta errado?

flw

Ih calcado desculpe mas eu vou discordar de vc quando diz que a inteligencia tem que estar nas classes entidade… pense na confusão!!!
Tipow segundo os livros que eu dei uma olhada isso não se pode fazer… é errado!!! :roll:

“twwwister”:

Ih calcado desculpe mas eu vou discordar de vc quando diz que a inteligencia tem que estar nas classes entidade… pense na confusão!!!
Tipow segundo os livros que eu dei uma olhada isso não se pode fazer… é errado!!! :roll:

• Qual confusao?
• Que livros?
• Por que errado?

A questao e simples: num modelo OO nao pode existir dado de um lado e “inteligencia” de outro. Se voce tem beans/entidades/qualquer coisa com apenas dados, voce esta praticando a boa e velha programaçao procedural e fugindo totalmente de OOP.

Sim, a grande maioria das pessoas coloca ogica de negocios em Commands, Actions, Session Beans ou algo do tipo e deixam estes manipular “netidades”, que neste contexto sao apenas agrupamentos de dados. Se voce tiver uma experiencia em C ou pascal, vai ver que isso nao eh nada diferente do que se faz enssas linguagens, onde estao os tais objetos?

De uma olhada:
http://www.fragmental.com.br/arquivos/fantoches.pdf

E por que sua tabela teria esse campo? Porque voce precisa de um atributo que identifique um registro? O principio eh o mesmo com objetos do tipo Entidade, eles precisam de alguma forma que os identifique. Sim, voce pode ter um campo id, como poderia identifica-lo por qualquer outro atributo, mas para criar uma identidade unica do objeto, nao pense em chaves-primarias, pense em identidade.

Faça seu metodoretornar um objeto cliente.

1 - Metodo recebe atributos
2 - Metodo faz o INSERT e recupera chave criada
3 -Metodo cria um objeto Cliente
4 - popula com atributos
3 - faz um setCodigo() no cliente com a chave criada
4 - retorna o cliente

Pronto

“pcalcado”:

Faça seu metodoretornar um objeto cliente.

1 - Metodo recebe atributos
2 - Metodo faz o INSERT e recupera chave criada
3 -Metodo cria um objeto Cliente
4 - popula com atributos
3 - faz um setCodigo() no cliente com a chave criada
4 - retorna o cliente

Pronto ;)

mas uma coisa quanto a isso:

é que pensando numa arquitetura em camadas eu num separaria as entidades (beans) das classes de negocio nao?
pra tentar fazer o maximo possivel com quem os beans assim como a view nao tenham logica de negocio?
pensando em ejbs teria os entity’s na modelo, session beans no controle e alguma coisa na view. ou estou errado?

normalmente eu faço assim :
os beans
daí os DAOs que fazem a interface destes com o banco.
algumas classes de controle que chamam as operaçoes do DAO e recebem os beans para executarem seus metodos de negocio e retornam pra alguma classe de apresentaçao.

isso é programação estruturada? nao entendo mais nada!
ahhhh!!!

Para falar sobre isso eu preciso saber: o que e um “bean” e o que eh uma “classe de negocio”?

Na maioria absoluta dos casos com uma aplicaçao web com 1 servidor so voce pode usar o seu proprio objeto de negocios como “bean”. Um dos unicos caso onde voce nao faria isso seria quando precisa usar o padrao VO/DTO/TO (que muita gente usa indiscriminadamente sem necessidade), que e para passar objetos entre nos numa rede ou entre JVMs.

certo Phillip,

saquei o que você ta falando.
mas agora falando da persistencia e nao mais das regras de negocio…
o ideal é coloca os metodos que persistem os dados no proprio objeto de negocio ou isolar isto em classes separadas?

e sim… li seu artigo la “fantoches”.
muito bom, parabens!

mas acho que vou ter que mudar meu jeito de programar, realmente faz sentido eu colocar cada classe “responsavel por si mesma”.
mas uma questao, voce disse que todo mundo tem mania de implementar esse “objetos burros” e criar classes “donas da razao” pra executar todas as operaçoes tirando a reusabilidade.
mas e se de repente o cliente cria um novo servidor aonde vai rodar parte da aplicação e voce, aonde nao precisava, tem que usar o VO/DTO/TO em muitas senao todas os seus “beans”.
e aí? voce vai perder tudo e ter que apelas para o copiar-e-colar?

ps. entenda-se por beans estes “objetos burros” e a classe de negocio os “donos da razao”

vlw[/code]

Existem varias maneiras de se fazer isso. Persistencia, como log, transaçoes e outras cosias, nao sao relativas a logica de negocio.

O mais utilizado eh a contruçao de uma camada de persistencia, geralmente com DAOs que recebem os objetos de negocio e sabem “uqebra-los” em tabelas relacionais.

Caso voce rpecise de DTOs para, por exemplo, passar objetos de um servidor para o outro, pode agrupar objetos d enegocio num “pacote” e despacha-lo pela rede

O padrao DTO em si ja eh uma gambiarra, quando se rpecisa utilizar isso, nao ha muito o que fazer.

hmm
mas se for uma aplicação aonde o trafego na rede é mais intenso. eu ficar transportando esses objetos de negocio com os metodos num pode sobrecarregar a rede mais do que se eu transportasse apenas “beans” ?

Oi,

Exatamente o oposto

Numa rede, eh melhor voce fazer o minimo de chamadas remotas possivel. Se voce empacotar beans ou objetos de negocio num DTO poara eliminar chamadas RPC em excesso, melhor.

http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

[]s

Cara que viagem… tem que separar a camada de negócios da de entidade… como é que eu bou tratar de uma regra de negócio (como um cálculo de faturamento ou outro cálculo) em uma classe de entidade? Totalmente fora de cogitação. Segundo oq li, claro!
Um bom exemplo é o livrinho do bezerra 2002. Ta tudo lah!!

Valeuww

nao nao…
oq Phillip disse faz sentido
ei, esclareceu legal pcalcado.
vlw :lol:

[]'s

phillip,

tava pensando e me apareceu mais uma duvida…
pq no exemplo que vc deu no texto fantoches fica facil entender que cada classe deve ser responsavel por ela mesma. afinal, a tarefa de estacionar um carro é dele mesmo.
mas vamo supor um controle de clientes.
as operaçoes de cadastro / alteração e exclusao devem ser feitas pelo proprio objeto cliente?
pq neste caso quem faz isso no mundo real é o funcionario!

[]'s

Oi,

“twwwister”:

Cara que viagem… tem que separar a camada de negócios da de entidade… como é que eu bou tratar de uma regra de negócio (como um cálculo de faturamento ou outro cálculo) em uma classe de entidade? Totalmente fora de cogitação. Segundo oq li, claro!
Um bom exemplo é o livrinho do bezerra 2002. Ta tudo lah!!

Nao conheço esse livro, apesar de ja ter ouvido falar dele. Infelizmente muitos livros e artigos, principalmente de JEE e EJB (nao sei se eh o caso) focam em separar “entidades” de “processamento” pela arquitetura se session beans. Na verdade, nem mesmo EJB prega isto, basta utilizar objetos de dominio para executar as regras.

Para aprender projeto OO, eu recomendo um livro classico, como o de Bertrand Meyer, u o mais conhecido “Aplicando UML e Padroes” (de preferencia a ediçao nova em ingles).

Voce cadastra o cliente onde?

Esse objeto “cadastro de clientes” deve ser responsavel pela adiçao e remoçao de clientes. Num livro muito legal chamado Domain Driven Design, Eric Evans propos um pattern chamado Repository. No seu caso, teriamos:

class GerenciadorClientes{

 CadastroClientes cadastro; //obter o rep via jndi, IoC, sei la

 public Cliente novoCliente(String nome){
  Cliente c = cadastro.criarNovo(nome);
  return c;
 }
}

class CadastroClientes {

 List clientes = new ArrayList();

 public Cliente novoCliente(String nome){
  Cliente c = new Cliente(nome);
  clientes.add(c);
  return c;
 }

}

ClientManager eh um façade, CadastroClientes um Repository.

Tem um resumo dos padroes do Evans aqui:

http://domaindrivendesign.org/book/index.html

e no fim das contas a classe cliente acaba sendo uma “classe burra”. só os get’s e set’s.

nao?

Nao necessariamente.

No caos eu so mostrei uma funcionalidade do repositorio, e como essa funçao nao eh responsabilidade do cliente, ele nao participa ativamente.

Este mesmo cliente poderia ter uma funcionalidade de calcular seus gastos, ou algo do tipo.

class Cliente{
 
 List<Pedido> pedidos = new ArrayList<Pedido>();

 public BigDecimal calcularGastos(){
  
  BigDecimal total = new BigDecimal();

  for(Pedido p : pedidos){
   total.add(p.getValor);
  }

   return total;
 }
}

A classe possui a implementacao das suas responsabilidades.

ahhh
agora fechou!

thanks!