Super JavaBeans: Milagre ou Maldição?

This message was edited 1 time. Last update was at 18/03/2005 15:09:38

Continuaçãod as discussões sobre JavaBeans deste topico.

fzampa wrote:
Ele diz para fazermos o seguinte

pag Jsp --> JavaBean Cliente --> JavaBeanUsaBanco

a pág. jsp usa o objeto cliente, com todos os seus atributos e getters e setters o qual chama o JavaBeanUsaBanco.

Como lingaugem de script, é bem razoável. Ah não, não é não. Use outra linguagem de script, até ASP fica melhor que isso.

Esta prática subutiliza o poder OO do Java. Se alguém quer fazer isso, ótimo, cada umt em sua cabeça, ams se você não quer diexar os benefícios dos objetos de lado, comece a tentar modelar sistemas sem beans.

Para começar, sua JSP deve única e exclusivamente gerar HTML, preferencialmente baseada nos atributos em escopo de request (sem acessar outros escopos ou processar nada).

Processamentod e regras de negócio? POJOs (google ou fórum). Processamentod e request HTTP? Servlets.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

Não estou falando que esta implementação é incorreta, pelo contrário
fundamentalmente é perfeita, mas se fomos analisar, muitos conceitos puros do OO são quebrados por causa de limitações tecnológicas.

Já pra começar temos esses getters e setters. São ridículos....
Fora um montão de coisas...

Me refiro a sistema distribuído como sistemas que tem componentes residentes em várias máquinas.(EJB, Web Services, CORBA, RMI, etc)

Um fator a se considerar é o número de chamadas na rede.
Outro fator é centralização das regras de negócio. Imagine você colocar as regras de negócio em objetos que estão localmente em várias máquinas diferentes. Iria-se no mínimo criar uma redundancia, fora a dificuldade de mudanças.

Então ao meu modo de ver é ideal o uso dos beans apenas para coleta e fornecimento de dados para os serviços, sendo eles EJB, Web Services, RMI ,etc. E esses fazendo ponte com as regras de negócio.

Temos que pensar sim no que pode acontecer com um sistema, isso garante a extensão da vida útil do mesmo.
Senão para que a gente se preocuparia com esses DAOs, Patterns e monte de coisas. Não existem apenas para garantir a reusabilidade e facilidade de manutenção.

This message was edited 1 time. Last update was at 18/03/2005 15:21:08

Aí, Shoes, então???

Essa forma de javabeans é bom ou ruim? Aquilo é OO?

Pra gravar tudo no banco de dados eu vou gravando e retorno tudo em boolean, entende? Se for false o retorno da gravação eu faço:

e na tela de exibição eu faço

Na verdade eu faço isso não só com o jsp, mas tb com tudo, inclusive nos programas superwaba... eu imaginava que este era um bom uso da OO.

@editado = enquanto eu perguntava isso as respostas de cima eram dadas

Rafael Nunes wrote:
Ja fiz de duas formas:
String nome = usuario.getNome(); e String nome = usuario.nome;

Pelo código ali então, eu deveria ter métodos que validassem meus atributos dentro do meu Bean?

Não, o ponto é: esqueça os beans e pense em objetos.

Meu mobjeto usuáriod eve sair mostrando a senha dele para todo mundo aí? No cotnexto do meu exemplo, não. A senah é secreta do usuário, então o que ele deve ter é um método para validar uma senha passada. Imagina se eu faço um getSenha que retorna uma senha criptografada, se você tentar usar este para pegar o valor e compará-lo em seguida, você vai ter que criptografá-lo.

Isso não é responsabildiade da classe cliente, mas sim da que oferece o serviço. Imagine o cneário:

Lembrando que você deveria modelar seu sistema próximo do mundo real, qual a melhor solução que alguém pdoeria implementar?

jprogrammer wrote:
Não estou falando que esta implementação é incorreta, pelo contrário
fundamentalmente é perfeita, mas se fomos analisar, muitos conceitos puros do OO são quebrados por causa de limitações tecnológicas.

Sim, muitos nem estão repsentes em Java ou em outras linguagens. mas os quesão possíveis devem (deveriam IMHO) ser utilizados.

jprogrammer wrote:
Já pra começar temos esses getters e setters. São ridículos....
Fora um montão de coisas...

Na verdade, essa limitação foi superada com metadados.

jprogrammer wrote:
Me refiro a sistema distribuído como sistemas que tem componentes residentes em várias máquinas.(EJB, Web Services, CORBA, RMI, etc)

Continua genérico

jprogrammer wrote:
Um fator a se considerar é o número de chamadas na rede.
Outro fator é centralização das regras de negócio. Imagine você colocar ...
fornecimento de dados para os serviços, sendo eles EJB, Web Services, RMI ,etc. E esses fazendo ponte com as regras de negócio.

Tá, você leu sobre o DTO? Porque, sabe, o padrão é justamente sobre isso

jprogrammer wrote:
Temos que pensar sim no que pode acontecer com um sistema, isso garante a extensão da vida útil do mesmo.
Senão para que a gente se preocuparia com esses DAOs, Patterns e monte de coisas. Não existem apenas para garantir a reusabilidade e facilidade de manutenção.

Se você for se preocupar com tudo que pode acotnecer, vai cair no erro semelhante a o de um modelo em cascata.

DAO e blablabla serve para fazer a arquitetura flexível qeu te falei.

This message was edited 2 times. Last update was at 18/03/2005 15:30:21

Acho que vou falar besteira mas vai lá:

Neste caso acima a classe Usuario então deveria ter um método que já retornasse a senha criptografada, e a classe CaixaEletronico passaria este método como parâmetro do método autenticar()?

Assim:

fzampa wrote:
Essa forma de javabeans é bom ou ruim? Aquilo é OO?

Eu não chamaria aquilo sequer de a forma correta de usar JSP, ams tem gente que discorda. Aquilo é JASP - JSP ahcando que é ASP.

fzampa wrote:
Pra gravar tudo no banco de dados eu vou gravando e retorno tudo em boolean, entende? Se for false o retorno da gravação eu faço:

Na verdade eu faço isso não só com o jsp, mas tb com tudo, inclusive nos programas superwaba... eu imaginava que este era um bom uso da OO.

@editado = enquanto eu perguntava isso as respostas de cima eram dadas

Entre a apresentação e a persistência fica sua camada de negócios, use ela

fzampa wrote:Pra gravar tudo no banco de dados eu vou gravando e retorno tudo em boolean, entende? Se for false o retorno da gravação eu faço:

this.status = false; this.msgErro = javaBeanBD.getMsgErro();

e na tela de exibição eu faço

if (!cliente.gravaCliente()) { msgErro = cliente.getMsgErro(); }

Na verdade eu faço isso não só com o jsp, mas tb com tudo, inclusive nos programas superwaba... eu imaginava que este era um bom uso da OO.

@editado = enquanto eu perguntava isso as respostas de cima eram dadas

Nossa, isso da uma quantidade de if enorme nao?

Rafael Nunes wrote:
Neste caso acima a classe Usuario então deveria ter um método que já retornasse a senha criptografada, e a classe CaixaEletronico passaria este método como parâmetro do método autenticar()?

Segundo esse racicío, eu tenho duas classes fazendo o mesmo trabalho (criptografando uma senha). Don't repeat yourself

todo mundo tem um if...

A interface grafica tem um if, o cliente tem if... todo mundo tem if

Cara, ainda nao tinha percebido... mas tem muito mesmo.

pcalcado wrote:
Entre a apresentação e a persistência fica sua camada de negócios, use ela

Assim, esse assunto tá sendo coisa nova pra mim.

O que teria na camada de negócios??? Seria onde eu trataria o cliente, o vendedor, o produto... é isso??? Como separar cada elemento?

This message was edited 1 time. Last update was at 18/03/2005 15:35:20

Segundo esse racicío, eu tenho duas classes fazendo o mesmo trabalho (criptografando uma senha).

Acho que eu to lesado hoje, não to notando a duplicação. A classe Usuario criptografa a senha, e a classe CaixaEletronico autentica(verificando se ela é válida ou não).

This message was edited 1 time. Last update was at 18/03/2005 15:38:58

Eu acho que os javabeans devem ser usados para representar as entidades em niveis granulares.
ex:

Aqui você tem desacoplamento, a classe login pode existir em apenas um lugar e posso ter a classe Usuario em vários. se eu mudar a implementação da autenticação mudo só em um lugar.

É OO puro, não , mais é funcional....

Felipe, pense assim...

Você é cotnratado para cosntruir um gerenciador de barraquinha de sorvete. Qual sua primeira atitude? pensar se é Hibernate/JSP/Velocity/Struts/WebWork ? Começou mal

Quando um cliente vira pra você dizendo: eu quero isso, isso e aquilo, ele te dá uma série de problemas que você precisa resolver através de um sistema. Vamos deixar a metodologia de lado (por agora) e pensar que você vai conseguir resolver tudo em uma versão só do software.

Pegue a lsita de problemas (conhecidos também nas rodas de samba como "requisitos"0 e os resolva utilizando apenas classes normais e testes unitários, aplciando padrões e toda a parafernalha OO de sempre, mas sem se preocupar com apresentação ou persistência.

Pronto, você tem sua camada de negócio

Se seu mdoelo for bom (e isso varia com experiência) você não vai ter que alterar muita coisa para colcoar isso em DAO, Hibernate, Entity Bean (ops, esse sim), Struts (Também), qualquer coisa...

Notícias, artigos e o maior fórum brasileiro sobre Java