[RESOLVIDO] Como um interage com outro?

Olá moça tudo bom? Voce nao precisa criar tres classes (Nome, Telefone…e por ai vai)…

Esses atributos vc pode deixar em uma classe “Pessoa”, sobre a classe intermediaria esta sera seu “Controller”, onde vc vai criar métodos que interaja com sua classe “Pessoa”, e no evento do botão cadastrar vc vai chamar seu método de cadastroPessoa(String nome, String telefone), e nesse metodo vc vai instanciar a classe Pessoa setando esses atributos, e guardando os objetos em um List por exemplo.

sim vc precisa de 3 classes sim

Pessoa 

    private List<Telefone> telefones
    private List<Email> emails

realmente é ideal q se tenha 1 classe controler

sua função é capturar os eventos da VIEW, e repassar ao processos corretos....

manipulação do banco de dados não deve ficar nos beans

Lavieri um objeto pessoa não contém, NOME, ENDEREÇO, TELEFONE, EMAIL?

contem 1 nome

porem contem Vários Endereços Telefones e Emails

Email pode ate ser uma String, mas deve ser dar preferencia a objetos que realmente representem o modelo.

e mesmo que só contenha um endereço, ele deve ser um objeto, com logradouro, numero, bairro, cep, bairro

telefone tem DDD, DDI, Numero, opicionalmente tem ramais

enfim e assim vai

Pra que criar esse tanto de classe?
Não há necessidade…
Cria um classe chamada pessoa, com telefone, endereço, etc

pedroroxd:

Pra que criar esse tanto de classe?
Não há necessidade…
Cria um classe chamada pessoa, com telefone, endereço, etc

faria do mesmo jeito…

Obrigada Everton e Lavieri por estarem ajudando colaborando com o tópico!

Lavieri:

sua função é capturar os eventos da VIEW, e repassar ao processos corretos…

manipulação do banco de dados não deve ficar nos beans

O que seriam os processos corretos? Os bean’s?
E quem chama a classe de manipulação do banco de dados?

Obrigada mais uma vez meninos! Fico no aguardo.

Olá Pedro!

pedroroxd:

Pra que criar esse tanto de classe?
Não há necessidade…
Cria um classe chamada pessoa, com telefone, endereço, etc

Então acho que o Lavieri esteja certo porque se uma pessoa da minha agenda tiver um monte de números de celulares, trabalho, etc…
Mas obrigada por tentar ajudar buscando facilitar… espero que continue atento ao tópico.

cada 1 faz o q acha melhor…

mas se um dia, vc estiver no projeto real, e ai o cara pedir: “Ó, naquele formulário onde tem ali 1 telefone, tem como por um celular ?”

ai vc vai na classe Pessoa e coloca um campo celular ?

ai depois o cara pede, “querido, tem gente que tem mais de 1 e-mail gostaria que vc registrasse todos os emails que a pessoa quiser colocar” … e ai ? vai ficar fazer o q ?

depois ele fala, “Filho precisamos abranger e registrar gente de outros estados… pra isso precisa registrar com dds difernetes, por favor incllui isso”

ai vc vai e … coloca novas propriedades… ddd_telefone, ddd_celular

ai ele manda, ó tem gente que tem 2 celulares, quero que ele possa registrar quantos telefones quiser

e ai ? vai ter q mudar sua lógica em todo canto, pois vai ter q tirar o telefone de dentro da pessoa…

…

isso são só alguns exemplos, o fato de fazer isso no inicio épra modelar direito, pra não sofrer no futuro… acha que nunca vai usar DDD ? nem DDI ? acha que nunca terá mais de um telefone ? acha que nunca vão te pedir pra registrar mais de um endereço pra 1 mesma pessoa ?

minimize seus problemas, pense logo tudo no inicio…

1 Pessoa é uma Pessoa
1 telefone é um telefone
1 email é um email
1 endereço é um endereço

não há sentido de fingir que tudo é uma pessoa quando não é

A pessoa tem algumas caracteristicas… vc coloca no objeto as relevantes, normalmente, Nome, Cpf, Nacionalidade, coisas que são inerentes a pessoa…

já Telefone, não é uma caracteristica da pessoa… então deve ter sua classe

O mesmo para endereço, email, e outras classes do tipo

…

Prefira a composição, não saia enfiando dentro de um objeto o que a ele não pertence

o normal é assim

public class Pessoa { private Integer id; //isso não faz parte do moelo, é pra uso qando se meche com banco de dados. private String nome; private String cpf; //pode ser também private Cpf cpf; private List<Endereco> enderecos; private List<Email> emails; private List<Telefone> telefones; private Cidade nacionalidade; }

public class Endereco { private Integer id; //não pertence ao modelo private String logradouro; private String numero; //número é um string pq nem sempre só contem números, por exemplo "S/N" private Bairro bairro; private String cep; private String complemento; }

public class Bairro { private Long id; //não pertence ao modelo private String nome; private String abreviacao; private Cidade cidade; //cidade segue a mesma logica, tendo um stado }

public class Telefone { private Integer ddi = 55; //quase sempre o ddi é 55 (brasil) private Integer ddd = 83; //pode colocar o padrao o do seu estado. private String numero; private String ramal; //opicional claro private TelefoneTipo tipo; //um enum com os tipos de telefone }

public enum TelefoneTipo { CELULAR, FIXO; //etc pode ter outro tipos }

enfim por ai vai

Bom vou da uma resumida!

Você vai criar uma Classe chamada DADOS PESSOAIS com as variáveis desejadas ex:“nome,endereço.telefone,e-mail” e fazer o GET e SET de cada variável!
Vai criar o FORM por os campos e etc…!
Criar uma classe de conexão também!

vlw

UMC:

Bom vou da uma resumida!

Você vai criar uma Classe chamada DADOS PESSOAIS com as variáveis desejadas ex:“nome,endereço.telefone,e-mail” e fazer o GET e SET de cada variável!
Vai criar o FORM por os campos e etc…!
Criar uma classe de conexão também!

vlw

pedroroxd:

UMC:

Bom vou da uma resumida!

Você vai criar uma Classe chamada DADOS PESSOAIS com as variáveis desejadas ex:“nome,endereço.telefone,e-mail” e fazer o GET e SET de cada variável!
Vai criar o FORM por os campos e etc…!
Criar uma classe de conexão também!

vlw

Foi o que eu sugeri…
Mas veio o espírito de porco (zuera), e deu a idéia de que uma pessoa poderia ter 2 telefones, 2 emails, e tal…
Ae teria que ser feito várias classes…

Bom a mocinha “dona do tópico” está com uma dificuldade básica! NORMAL para início!
fazer várias classes “FALA sério!”
Vai bagunçar tudo!

vlw

Concordo plenamente…
Para mim seria a classe Pessoa com get’s e set’s

pedroroxd:

Concordo plenamente…
Para mim seria a classe Pessoa com get’s e set’s

vlw

ingridfarabulini:

Obrigada Everton e Lavieri por estarem ajudando colaborando com o tópico!

Lavieri:

sua função é capturar os eventos da VIEW, e repassar ao processos corretos…

manipulação do banco de dados não deve ficar nos beans

O que seriam os processos corretos? Os bean’s?
E quem chama a classe de manipulação do banco de dados?

Obrigada mais uma vez meninos! Fico no aguardo.

assim

vc poem um controlador como Ouvinte do botão…

quando o botão é clicado, o Controlador, pega os dados do formulario, popula um Bean com os dados (isso se os dados já não estiverem em um bean)

ai esse controlador deve ter o papel, de saber quem é o responsável por guardar os beans em um banco de dados (Normalmente esse bean é chamado de entity, por ser possivel persitilo em um banco) e normalmente esse objeto, no inicio é um DAO (Data Access Object) que conhece como conversar como banco, e é responsavel por guardalo no banco…

Então resumindo…

Swing, responsavel pela exibição, e por receber os dados atraves da VIEW.

COntroller, responsável por entermediar o que vem da VIEW, e repassar para lógicas responsáveis pelo processo

por exemplo

public class Controller implements EventoQualquerListener{ //ou seja escuta um evento qualquer da view public void eventoQualquer(EventoOcorrido evento, Object source) { //aqui vc tem q pegar o bean do source, e passar ele pra um lógica //algo como Pessoa p = new Pessoa(); p.setNome(source.getLocalOndeGuardaNome().getText()); //e depois de estar com o bean OK PessoaDao dao = //pega o pessoa dao dao.save(pessoa); } }

quanto mais desacomplado, ou seja, quanto menos operações tiver dentor do Controller melhor… ele deve simplismente pegar o que esta na VIEW (no swing) e repassar para a lógica… normalmente a lógica não é um DAO… e sim um objeto que tem toda a lógica que deve ocorrer ao ser enviado um bean…

ai é esse objeto

Olá Lavieri, entendi sua explicação ficou bem clara!

Nesse caso então a classe Pessoa vai ter um método de cadastrar no qual irá receber os dados também de telefone, e-mail,…
Ex:

public void cadastrarPessoa(String nome, String sobrenome, Telefone tel, Email mail) {
  //...
}

Seria isso?
Também ainda estou com a dúvida da sua primeira resposta lá em cima… e que foram muitas respostas acho que passou despercebida minha dúvida…
Obrigado por estar me ajudando… espero que continue aqui no tópico.

UMC:

pedroroxd:

UMC:

Bom vou da uma resumida!

Você vai criar uma Classe chamada DADOS PESSOAIS com as variáveis desejadas ex:“nome,endereço.telefone,e-mail” e fazer o GET e SET de cada variável!
Vai criar o FORM por os campos e etc…!
Criar uma classe de conexão também!

vlw

Foi o que eu sugeri…
Mas veio o espírito de porco (zuera), e deu a idéia de que uma pessoa poderia ter 2 telefones, 2 emails, e tal…
Ae teria que ser feito várias classes…

Bom a mocinha “dona do tópico” está com uma dificuldade básica! NORMAL para início!
fazer várias classes “FALA sério!”
Vai bagunçar tudo!

vlw

e do inicio que se começa a fazer tudo errado …

Começar a programar errado, vai dar problema depois… é mais que provado, se perde mais tempo com manutenção com desenvolvimento… e o motivo são ideis simplistas como colocar [telefone removido] dados dentro de um classe onde deveriam estar corretamente encapsuladas…

Vou dar outro exemplo

Pessoa com campos de endereço dentro dela…

ai vc tem um Forncedor com seus campos de endereços dentro dela… ai vc quer fazer uma mala direta para pegar os endereços… e ai vem a encrenca…

vai ter q criar 2 lógicas, uma pra Pessoa outra pra fornecedor, pois cada um tem seus proprios endereços…
…

No mundo real é assim que acontece… alguem te pede algo, vc pensa simples, monta o sistema todinho, ai vc passa pro cara o programa, ele nunca falou nada de 2 teleofnes… mas assim q inicia, um usuario sente falta, e já reclama pede pra vc mudar… e uma coisa besta, como ter 2 telefones, faz vc alterar dezenas e dezenas de linhas de código, que antes buscavam o telefone diretamente na pessoa, e não em um objeto proprio…

UMC:

pedroroxd:

UMC:

Bom vou da uma resumida!

Você vai criar uma Classe chamada DADOS PESSOAIS com as variáveis desejadas ex:“nome,endereço.telefone,e-mail” e fazer o GET e SET de cada variável!
Vai criar o FORM por os campos e etc…!
Criar uma classe de conexão também!

vlw

Foi o que eu sugeri…
Mas veio o espírito de porco (zuera), e deu a idéia de que uma pessoa poderia ter 2 telefones, 2 emails, e tal…
Ae teria que ser feito várias classes…

Bom a mocinha “dona do tópico” está com uma dificuldade básica! NORMAL para início!
fazer várias classes “FALA sério!”
Vai bagunçar tudo!

vlw

Olá UMC, obrigada por estar tentando ajudar!
Mas sinceramente essa divisão de classes eu já havia aprendido… Na minha opinião, me desculpa eu discordar da sua, mas realmente se torna necessário criá-las!
Aqui mesmo na minha agenda do telefone tem algumas pessoas que tem mais de um número (para ser sincera, quase todos :D)…
Volto a agradecer por estar tentando ajudar facilitando, ok? Não fica chateado.

Blz, então vai pela do Lavieri
Só que da preguiça só de ler as mensagens dele! kkkk

Lavieri Calma ae!!!

Você está errado !

Blz, então vai pela do Lavieri
Só que da preguiça só de ler as mensagens dele! kkkk

vlw

ingridfarabulini:

Olá Lavieri, entendi sua explicação ficou bem clara! Nesse caso então a classe Pessoa vai ter um método de cadastrar no qual irá receber os dados também de telefone, e-mail,... Ex:

public void cadastrarPessoa(String nome, String sobrenome, Telefone tel, Email mail) {
  //...
}

Seria isso?
Também ainda estou com a dúvida da sua primeira resposta lá em cima... e que foram muitas respostas acho que passou despercebida minha dúvida...
Obrigado por estar me ajudando... espero que continue aqui no tópico. :wink:

cadastarPessoa não.... na verdade seria algo como

public clas Pessoa {
    //todo os campos
    
    //ai vc tem o getter e os setter para ajustar os valores dos campos e não um cadastarPessoa
}

public class Pessoa {
     public Pessoa(String nome, String sobrenome, Telefone tel, Email mail) {
       this.nome = nome;
       this.sobrenome= sobrenome;
       this.tel = tel; //etc etc etc
     }
}

quem vai realmente cadastar uma pessoa, é o DAO ou algo do genero, ele vai receber o objeto Pessoa, e guardar esse objeto dentro de um banco de dados...

depois quando vc precisar resgatar esse objeto, vc pede para o DAO, e ele fica responsável por pegar esse objeto devolta do lugar onde ele guardou....

Uma pessoa Não cadastra ela mesma...

os métodos save, delete, update entre outros, não são inerentes da pessoa, e sim de outro objeto....

Não existe certo e errado

UMC:

Lavieri Calma ae!!!

Você está errado !

Blz, então vai pela do Lavieri
Só que da preguiça só de ler as mensagens dele! kkkk

concordo!

vlw

não estou nem mais certo, nem mais errado que vc =P

o fato é que vc esta sendo simplista, e eu estou seguindo a orientação a objeto, a regra da coesão e da separação das responsabilidades…
se vc não gosta paciencia…

Lavieri:

blablabla . .

public clas Pessoa {
    //todo os campos
    
    //ai vc tem o getter e os setter para ajustar os valores dos campos e não um cadastarPessoa
}

. . . blablabla

Lavieri:

UMC:

Lavieri Calma ae!!!

Você está errado !

Blz, então vai pela do Lavieri
Só que da preguiça só de ler as mensagens dele! kkkk

concordo!

vlw

não estou nem mais certo, nem mais errado que vc =P

o fato é que vc esta sendo simplista, e eu estou seguindo a orientação a objeto, a regra da coesão e da separação das responsabilidades…
se vc não gosta paciencia…

Com esse tópico tiro certificação JAVA!

Tira mesmo, fácil fácil…
Tudo da linguagem de programação Java se baseia nos tópicos acima

pedroroxd:

Blz, então vai pela do Lavieri
Só que da preguiça só de ler as mensagens dele! kkkk

ahhh outra coisa… no mundo real… um pedido como “transforma 1 telefone único, encapsulado dentro de cada classe que precisou de telefones em multiplos telefones separado em um objeto proprio onde possa ser reutilizado” da cerca de 200% mais trabalho do que fazer todo o sistema OO desde o inicio e nunca precisar dele tão OO afinal.

mas cada 1 tem sua ideia…

Sou adepto da explicação do Lavieri. Muito melhor dividir corretamente as responsabilidades do que ter q fazer POG depois.

Concordo, mas a menina é iniciante…
Nem deve ter visto de List e array

Cara, cuidado com suas palavras!

Lavieri:

ingridfarabulini:

Obrigada Everton e Lavieri por estarem ajudando colaborando com o tópico!

Lavieri:

sua função é capturar os eventos da VIEW, e repassar ao processos corretos…

manipulação do banco de dados não deve ficar nos beans

O que seriam os processos corretos? Os bean’s?
E quem chama a classe de manipulação do banco de dados?

Obrigada mais uma vez meninos! Fico no aguardo.

assim

vc poem um controlador como Ouvinte do botão…

quando o botão é clicado, o Controlador, pega os dados do formulario, popula um Bean com os dados (isso se os dados já não estiverem em um bean)

ai esse controlador deve ter o papel, de saber quem é o responsável por guardar os beans em um banco de dados (Normalmente esse bean é chamado de entity, por ser possivel persitilo em um banco) e normalmente esse objeto, no inicio é um DAO (Data Access Object) que conhece como conversar como banco, e é responsavel por guardalo no banco…

Então resumindo…

Swing, responsavel pela exibição, e por receber os dados atraves da VIEW.

COntroller, responsável por entermediar o que vem da VIEW, e repassar para lógicas responsáveis pelo processo

por exemplo

public class Controller implements EventoQualquerListener{ //ou seja escuta um evento qualquer da view public void eventoQualquer(EventoOcorrido evento, Object source) { //aqui vc tem q pegar o bean do source, e passar ele pra um lógica //algo como Pessoa p = new Pessoa(); p.setNome(source.getLocalOndeGuardaNome().getText()); //e depois de estar com o bean OK PessoaDao dao = //pega o pessoa dao dao.save(pessoa); } }

quanto mais desacomplado, ou seja, quanto menos operações tiver dentor do Controller melhor… ele deve simplismente pegar o que esta na VIEW (no swing) e repassar para a lógica… normalmente a lógica não é um DAO… e sim um objeto que tem toda a lógica que deve ocorrer ao ser enviado um bean…

ai é esse objeto

Não entendi uma coisa: O source vai ter um objeto com as informações para que eu possa popular um outro objeto da classe Pessoa, certo?
Que objeto é esse?

Obrigada Lavieri está me ajudando muito!
Meninos, por favor parem de brigar, eu sei que é para tentar ajudar… mas não precisam brigar!

UMC:

Cara, cuidado com suas palavras!

É sim… concordo!

ingridfarabulini:

Meninos, por favor parem de brigar, eu sei que é para tentar ajudar… mas não precisam brigar! :(

ingridfarabulini:

Não entendi uma coisa: O source vai ter um objeto com as informações para que eu possa popular um outro objeto da classe Pessoa, certo?
Que objeto é esse?

Obrigada Lavieri está me ajudando muito!
Meninos, por favor parem de brigar, eu sei que é para tentar ajudar… mas não precisam brigar! :(

é que normalmente um evento é passado assim… ou o evento e o source… ou no evento tem um método para pegar o source…

o source é quem gerou o evento… por exemplo… ao clicar no botão de uma janela swing, o source é normalmente quem gerou o evento, no caso o botão… ou a janela…

a partirdai, vc vai ter acesso aos campos Texto do Swing, ou os campos podem estar diretamente bindados a uma entity, e vc pega a entity diretamente… depende de como vc faz a janela…

o fato é… no evneto disparado… vc recebe quem o disparou, a paritir disso vc pega os dados que estão neste objeto… se for uma janela com os forms, vc a paritr da janela e dos forms, vc achaa os valores, e coloca elas dentro de um bean, e manda ele pra lógica tratar corretamente…

Concordo, mas a menina é iniciante…
Nem deve ter visto de List e array

Oi Pedro! Conheço sim… já estudei eles na documentação do Java. Podem falar sobre eles que consigo entender… qualqeur coisa recorro a documentação.

Lavieri:

o source é quem gerou o evento… por exemplo… ao clicar no botão de uma janela swing, o source é normalmente quem gerou o evento, no caso o botão… ou a janela…

a partirdai, vc vai ter acesso aos campos Texto do Swing, ou os campos podem estar diretamente bindados a uma entity, e vc pega a entity diretamente… depende de como vc faz a janela…

o fato é… no evneto disparado… vc recebe quem o disparou, a paritir disso vc pega os dados que estão neste objeto… se for uma janela com os forms, vc a paritr da janela e dos forms, vc achaa os valores, e coloca elas dentro de um bean, e manda ele pra lógica tratar corretamente…

Vamos ver se entendi: Quando eu clico no botão, o objeto Event (source) gerado para o ActionListener vai ser, por exemplo, o objeto JanelaAgenda? É isso?
Obrigada! :-o

ingridfarabulini:

Lavieri:

o source é quem gerou o evento… por exemplo… ao clicar no botão de uma janela swing, o source é normalmente quem gerou o evento, no caso o botão… ou a janela…

a partirdai, vc vai ter acesso aos campos Texto do Swing, ou os campos podem estar diretamente bindados a uma entity, e vc pega a entity diretamente… depende de como vc faz a janela…

o fato é… no evneto disparado… vc recebe quem o disparou, a paritir disso vc pega os dados que estão neste objeto… se for uma janela com os forms, vc a paritr da janela e dos forms, vc achaa os valores, e coloca elas dentro de um bean, e manda ele pra lógica tratar corretamente…

Vamos ver se entendi: Quando eu clico no botão, o objeto Event (source) gerado para o ActionListener vai ser, por exemplo, o objeto JanelaAgenda? É isso?
Obrigada! :-o

vai ter um source, de onde o evento foi disparado… esse source acho que é o botão, e não a janela… porem no botão tem como vc pegar a janela onde ele esta contido… e assim conseguir achar os dados que vc quer…

está vendo no que dar tanta explicação!
confusão na explicação!!

Lavieri:

ingridfarabulini:

Lavieri:

o source é quem gerou o evento… por exemplo… ao clicar no botão de uma janela swing, o source é normalmente quem gerou o evento, no caso o botão… ou a janela…

a partirdai, vc vai ter acesso aos campos Texto do Swing, ou os campos podem estar diretamente bindados a uma entity, e vc pega a entity diretamente… depende de como vc faz a janela…

o fato é… no evneto disparado… vc recebe quem o disparou, a paritir disso vc pega os dados que estão neste objeto… se for uma janela com os forms, vc a paritr da janela e dos forms, vc achaa os valores, e coloca elas dentro de um bean, e manda ele pra lógica tratar corretamente…

Vamos ver se entendi: Quando eu clico no botão, o objeto Event (source) gerado para o ActionListener vai ser, por exemplo, o objeto JanelaAgenda? É isso?
Obrigada! :-o

vai ter um source, de onde o evento foi disparado… esse source acho que é o botão, e não a janela… porem no botão tem como vc pegar a janela onde ele esta contido… e assim conseguir achar os dados que vc quer…

Desculpa, mas não consigo visualizar essa situação. Àlias, não vou estar acoplando demais a visão ao controlador? Obrigada.

ingridfarabulini:

Desculpa, mas não consigo visualizar essa situação. Àlias, não vou estar acoplando demais a visão ao controlador? Obrigada.

vai

mas um controlador é acoplado a view e a lógica de modelo…

ele é o intermedio, então ele tem q conhecer os 2… o objetivo dele, é transformar a view em algo que a lógica entenda…

o objetivo é tirar da lógica a responsabilidade disso… e tirar da view a responsabilidade de saber o que a lógica quer…

…

o Controlador que fica no meio, é quem conversa com os 2 … e por isso ele entende os 2

Edit.: na view vc pode ate linkar seus campos a aos benas, e assim que xega mais mastigadinho no controlador

De tanto explicação…
CONFUSÃO NA EXPLICAÇÃO !

Lavieri:

o que vc pode ter é um construtor, para poder passar os dados todos de um vez, e ja ter uma pessoa completa, por exemplo

public class Pessoa { public Pessoa(String nome, String sobrenome, Telefone tel, Email mail) { this.nome = nome; this.sobrenome= sobrenome; this.tel = tel; //etc etc etc } }

quem vai realmente cadastar uma pessoa, é o DAO ou algo do genero, ele vai receber o objeto Pessoa, e guardar esse objeto dentro de um banco de dados…

depois quando vc precisar resgatar esse objeto, vc pede para o DAO, e ele fica responsável por pegar esse objeto devolta do lugar onde ele guardou…

Uma pessoa Não cadastra ela mesma…

os métodos save, delete, update entre outros, não são inerentes da pessoa, e sim de outro objeto…

Sim, entendi. Mas quem chama a DAO é o controller? Ou o Bean?

ahh e lembrando… é por isso, que eu falei, que no controlador vc deve ter o minimo possivel de lógica nele. e ele deve passar isso pra alguma lógica responsável…

pois a lógica tem q ser mantida… ou seja… o processo desencadeado após receber o bean, em um cadastro, deve ser separado, em um local adequado…

…

se um dia (não que isso aconteça facilmente) trocar a view pra outra coisa… vc remove a view… escreve um controlado novo pra view nova, e envia o bean pra lógica… e a lógica fica preservada…

Hmm
tive uma idéia melhor…
Porque você não crie apenas uma classe chamada pessoa, com variáveis Nome, Endereço, Telefone
E depois faz os get’s e set’s como o pedroroxd e o UMC falou?

normalmente funciona assim …

VIEW -> CONTROLLER -> LOGICA (onde tem os processos) -> CAMADA DE PERSISTENCIA (o que pode ser um DAO).

a lógica e a camada de persistencia que comentei aqui, fazem parte do MODELO

portanto… MVC (Modelo Visão e Controle).

normalmente é assim q faz

ahh e lembrando… é por isso, que eu falei, que no controlador vc deve ter o minimo possivel de lógica nele. e ele deve passar isso pra alguma lógica responsável…

pois a lógica tem q ser mantida… ou seja… o processo desencadeado após receber o bean, em um cadastro, deve ser separado, em um local adequado…

…

se um dia (não que isso aconteça facilmente) trocar a view pra outra coisa… vc remove a view… escreve um controlado novo pra view nova, e envia o bean pra lógica… e a lógica fica preservada…

Uhmm acho que estou entendo. Então quer dizer que o bean não faz parte do modelo?
Vamos ver, olha só:

• A visão será a classe CadastraPessoaVisao (que contém os campos para cadastrar);
• O controlador será a classe PessoaControla que escuta os eventos ocorridos no objeto criado de CadastraPessoaVisao (exemplo do clique no botão cadastrar);
• A logica seriam as classes Pessoa, Telefone, EMail;
• Esse mesmo controlador fica responsável em carregar os dados em um objeto da classe Pessoa (a qual carregará os demais objetos instanciados por ela, no caso Telefone, Email)

Certo?

Favor evitar cantadas baratas em cima das mulheres que frequentam o fórum. Mensagens apagadas.

Os beans fazem sim parte do modelo …

Modelo inclui, suas entidades (os beans), suas lógicas (as operações a serem realizadas em seu modelo), e também o limiar com a camada de persistencia (ou seja, lógicas de consulta, de inserção entre outras coisas)…

Uma primeira observação, apesar das entidades (esses beans que vc esta falando) serem parte do modelo, normalmente eles trafegam por todas as camadas, desde a visão, onde podem ser recebidos para exibição ou preenchimento, passando pelo controle (que os extrai da visão e joga pra lógica, ou os recebe como resultado de um lógica e envia para o lugar adequado na visão), pela lógica (que processa e realiza operação a partir dessas entidades) até a camda de persistencia (que recebe da lógica para armazenamento no banco, ou para remoção ou atualização no banco; ou puxando do banco de dados e enviado como retorno para a lógica).

A entidade (Por exemplo um objeto Pessoa) é um objeto que navega em todas as camadas, existem casos que a visão não o conhece e nesses casos o controlador tem que os converter para a visão conseguir exibir, em casos que a visão consegue trabalhar com as entidades, o controlador não precisa se dar ao trabalho disto

Vendo as responsabilidades

• A Visão cuida de iteragir com o usuários, para tal pode ser com campos e formulário para cadastro, ou exibindo informações, entre outras coisas.

• O Controlador tem a função de entender o que o usuário pede a visão, e conhecer as rotas do seu sitema, enviado uma requisição do usuário para a lógica correta, além de receber o resultado de uma ação pedida a lógica, e devolver para a visão correta, para que o usuário tenha o seu retorno.

• A Lógica tem função de processaro um pedido, uma requisição do usuário, fazer os passos necessário para que o evento ocorra conforme pedido pelo usuário, para tal ele conhece que o procedimento para efetivamente fazer o pedido, para tal ele pode se comunicar com varios setores do modelo, como por exemplo, cadastrar a Pessoa no através do PessoaDao, enviar um e-mail para o administrador, informando que existe uma nova pessoa, checar se tudo ocorreu bem… alem disso uma lógica pode requerer informações, processar as informações e entregar de volta para quem pediu (no caso o controle). Essa lógica então fala com o a camada de persistencia sempre que é necessário recuperar dados armazenados ou armazenar dados.

• A Camada de persistencia é quem cuida de guardar, remover, atualizar, ou também recuperar as entidades de um banco de dados fisico, é responsável pelas consultas e coisas do genero, ela retorna pra lógica o resultado de suas consultas, ou de suas operações.

• As Entidades (ou os beans como vc esta chamando) são na verdade a informação, que esta sendo passada entre as camadas, elas podem ou não conter alguns processos, e ter algumas lógicas internas, mas normalmente são só isso, um punhado de informação, que tranzita entre as camadas… são informações enviadas pelo usuário, ou atualizadas pelo usuário, ou apagadas, ou coisas do tipo… essa é a função principal destas entidades servir de informação…

…

Espero que tenha entendido, e desculpa a demora na resposta, é que dei uma saida, e só voltei agora…

Olá Lavieri, eu entendi sim.

As entidades caminham por todas as camadas levando os dados necessários para processamento em outras camadas.

Vou tentar mostrar isso:

• Eu abro a janela de cadastro da minha agenda; (um objeto de CadAgenda)
• Nela preencho os dados da pessoa que vou cadastrar; (os JTextField’s)
• Clico no botão cadastrar; (o JButton)
• Nesse momento, o ActionListener do JButton (que está dentro do objeto CadAgenda) cria um objeto de Pessoa (entidade) e através dos set’s passa os dados dos JTextField para o objeto criado;
• Por fim o ActionListener chama um método do Controle ( control.cadastrar(Pessoa p) ) passando o objeto de Pessoa para ele;
• Encerra-se o ciclo da visão por hora…

Até aqui tudo certo?
Obrigada Desculpa se estiver entendendo errado… :oops:

Ahhhh
mankdaaaaaa
HUAhuUAHuha
eu tava bebado =X

Ahhhh
mankdaaaaaa
HUAhuUAHuha
eu tava bebado =X

rs… ainda bem que sou compromissado… mensagem privada para olhar o tópico e com foto do sexo oposto, já logo pensei… vai chover reply… rs…

Ahhhh
mankdaaaaaa
HUAhuUAHuha
eu tava bebado =X

rs… ainda bem que sou compromissado… mensagem privada para olhar o tópico e com foto do sexo oposto, já logo pensei… vai chover reply… rs…

É moço e pelo que parece está difícil alguém conseguir entender a minha pergunta aí de cima para responder…
Estou vendo outros tópicos também… mas até agora não consigo visualizar direito como fazer essa agenda…
Obrigada por ter atendido ao meu MP e fico feliz que tenha respondido aqui, como citei não gosto de usar MP porque a resposta fica restrita e desfavorece os demais usuários do fórum. Parabéns moço! Fico no aguardo por mais respostas, quem souber… ficarei grata!

Olá moça, tudo bem com você?
Muito obrigado mesmo por ter entrado em contato comigo pela mensagem privada. Fiquei muito feliz de receber sua mensagem hoje!

Olha só li sua dificuldade e já passei por isso no ano passado, álias até hoje tenho minhas dúvidas também sobre arquitetura…kkk.
Precisei ficar ausente do fórum até quase final de Janeiro… mas me inspirou a voltar!
Mas veja este tópico aqui do GUJ mesmo que criei no ano passado, acredito eu que irá ajudá-la e muito a sanar sua dúvida!!! Link
Olha para você, exclusivamente, vou até montar uma imagem com a última explicação que foi dada pelo Sergio Taborda que na minha opinião foi a que mais convenceu…
Vou colocar a imagem lá no tópico… também sou adepto ao que disse na mp de evitar fechar a informação a todos… ela deve transcorrer livremente, sem dúvida, para todos os companheiros Gujeiros.

Leia com calma cada detalhe lá do tópico, não se afobe em fazer uma nova pergunta, ok?
Tudo de bom para você, conheço Canasvieiras já passei uma férias aí no litoral de Santa Catarina.
Mais uma vez obrigado por me procurar, sempre que precisar, ok?

mais ou meno assim

public class AgendaUI { //esse é o seu controle principal
	private JFrame janela;
	private JPanel painelPrincipal;
	//os campos de onde vc quer pegar dados.
     
	public void montaTela() {
		montaJanela();
		montaPainelPrincipal();
		montaTitulo();
		montaFormulario()
		montaBotaoCadastrar();
		montaBotaoSair();
		mostraJanela();
	}

	private void montaJanela() {
		janela = new JFrame("Agenda v0.1");
		janela.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
	}

	private void montaTitulo() {
		JLabel titulo = new JLabel("Agenda Cadastramento");
		titulo.setFont(new Font("Verdana", Font.BOLD, 25));
		titulo.setForeground(new Color(55, 52, 100));
		titulo.setHorizontalAlignment(SwingConstants.CENTER);
		painelPrincipal.add(titulo);
	}
	
	private void montaFormulario() {
		//aqui vc coloca o formulario dentro do painelPrincipal
		//e guarda referencia para conseguir pegar os dados dos campos.
	}

	private void montaBotaoCadastrar() {
		JButton botacaoCadastrar = new JButton("Cadastrar");
		botacaoCarregar.addActionListener(new ActionListener() {
			@Override
			public void actionPerformed(ActionEvent arg0) {
				//pega os campos do formulário, e coloca dentro do bean Pessoa
				new LogicaDaAgenda().cadastrar(pessoa); //aqui vc delega para lógica cadastrar
				//operacoes para apagar os dados do formulário
			}
		});
		painelPrincipal.add(botacaoCadastrar );
	}

	private void montaBotaoSair() {
		JButton botaoSair = new JButton("Sair");
		botaoSair.addActionListener(new ActionListener() {
			@Override
			public void actionPerformed(ActionEvent e) {
				System.exit(0);
			}
		});
		painelPrincipal.add(botaoSair);
	}

	private void mostraJanela() {
		janela.pack();
		janela.setSize(600, 600);
		janela.setVisible(true);
	}
}

é + ou - assim

Lavieri:

mais ou meno assim

public class AgendaUI { //esse é o seu controle principal
	private JFrame janela;
	private JPanel painelPrincipal;
	//os campos de onde vc quer pegar dados.
     
	public void montaTela() {
		montaJanela();
		montaPainelPrincipal();
		montaTitulo();
		montaFormulario()
		montaBotaoCadastrar();
		montaBotaoSair();
		mostraJanela();
	}

	private void montaJanela() {
		janela = new JFrame("Agenda v0.1");
		janela.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
	}

	private void montaTitulo() {
		JLabel titulo = new JLabel("Agenda Cadastramento");
		titulo.setFont(new Font("Verdana", Font.BOLD, 25));
		titulo.setForeground(new Color(55, 52, 100));
		titulo.setHorizontalAlignment(SwingConstants.CENTER);
		painelPrincipal.add(titulo);
	}
	
	private void montaFormulario() {
		//aqui vc coloca o formulario dentro do painelPrincipal
		//e guarda referencia para conseguir pegar os dados dos campos.
	}

	private void montaBotaoCadastrar() {
		JButton botacaoCadastrar = new JButton("Cadastrar");
		botacaoCarregar.addActionListener(new ActionListener() {
			@Override
			public void actionPerformed(ActionEvent arg0) {
				//pega os campos do formulário, e coloca dentro do bean Pessoa
				new LogicaDaAgenda().cadastrar(pessoa); //aqui vc delega para lógica cadastrar
				//operacoes para apagar os dados do formulário
			}
		});
		painelPrincipal.add(botacaoCadastrar );
	}

	private void montaBotaoSair() {
		JButton botaoSair = new JButton("Sair");
		botaoSair.addActionListener(new ActionListener() {
			@Override
			public void actionPerformed(ActionEvent e) {
				System.exit(0);
			}
		});
		painelPrincipal.add(botaoSair);
	}

	private void mostraJanela() {
		janela.pack();
		janela.setSize(600, 600);
		janela.setVisible(true);
	}
}

é + ou - assim

Olá Lavieri...
Entendi sim... nesse caso então o ActionListener faz o papel de chamar a lógica da aplicação certo?
Esse código que me mostrou seria da apresentação??
Obrigada por não desistir! :D

é um controlador que monta chama uma visão… e é responsável por sua comunicação com as camadas de baixo…

pra exibir essa janela é facil

public static void main(String[] args) { new AgendaUI().mostraJanela(); }

os componenetes, que são JFrame e eoutros podem ser Objetos personalizados com as telas pra pre montadas…

e sendo objetos montados, fica mais separado a visão da lógica, pq ai é melhor do que montar a tela no controlador

Entendi sim!
É acredito que sanou uma das minhas dúvidas principais!
Obrigada mais uma vez por toda sua atenção!
Tenho mais umas dúvidas mas um colega acima indicou um tópico que achei interessante e como já está caminhada a conversa vou postar lá para não ficar duplicando tópicos!
Mais uma vez obrigada mesmo, beijo.

vc pode montar uma visão Mais desacoplada assim

AgendaJFrame {
       //sua montagem
       public void addBotacaoCadastrarLisneter(ActionListener listener) {
              botacaoCadastrar.addActionListener(lisitener); 
       }

       public String getCampoXValor() {
            return //retorna o valor do campo;
       }
       pulbic void setCampoXValor(String valor){
       }

       //e assim por diante
}

ai no controlador vc faz

AgendaJFrame agenda = new AgendaJFrame();
agenda.addBotacaoCadastrarLisneter(new ActionListener() {
   //....
    aqui vc pega os valores dos campos
});
agenda.mostrarTela();

Observação, é possivel linkar os valores dos campos a propriedades de um bean, não lembro exatamente como é, e nem lembro se é apenas uma gambiarra do netbeans.

Legal! Mais uma vez obrigada! Beijo.

Bão, o pessoal está dando muita ajuda, mas como pediram pra eu vir até aqui

Não acompanhei toda a Thread, por tanto, se tiver algo duplicado no meu comentário, desconsiderem.

O “bean” o qual você se refere, que representa seu Domínio, pode ser sim o mesmo que “aparece” na camada view (tela).

Este também será responsável pela persistência, você não precisa criar uma classe de mapeamento e copiar os parâmetros e se quiser fazer algo mais Domain-Driven Design, sua lógica inerente ao domínio pode estar contida na classe.

O que eu quero dizer com isso ? - http://martinfowler.com/bliki/AnemicDomainModel.html e pra facilitar sua leitura - http://en.wikipedia.org/wiki/Anemic_Domain_Model

Então sua classe “Pessoa” que contém relacionamento com outros objetos como “Endereço”, ela sabe se salvar e possui alguma política de validação.

Para os demais amigos num estágio mais avançado, aconselho a leitura do artigo - http://www.infoq.com/articles/ddd-in-practice

Bão é isso

Bem, como também me fizeram contato por MP, vou dar a dica do motivo de se usar camadas. Provavelmente já ter te falado isso, mas…
Você está programando sua tela em Swing, e provavelmente o seu código deve ter uma porção de coisa nas ações dos botões. Há um alto acoplamento entre a Visão (tela), o Controle e o Modelo (dados do banco). Agora vamos supor que um dia o seu cliente decide que o sistema tem que funcionar como uma aplicação Web, pois ele está expandindo seus negócios e quer que outras regiões do Brasil ou do mundo também usem o aplicativo. Se você seguiu os padrões recomendados do MVC vai ser simples mudar a camada de visão para se adaptar numa aplicação que rode na Web. Caso contrário, provavelmente terá que reconstruir todo o sistema.
Mas é interessante você ter esses problemas porque daí passa a entender os motivos da aplicação de vários Design Patterns.