Super JavaBeans: Milagre ou Maldição?

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

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.

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.

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:


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

[quote=Rafael Nunes]
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? [/quote]

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:

class CaixaEletronico{

public void autenticar(String senha){...}

public void setUsuarioAtual(){...}

}

class Usuario{
String getSenha(){...}
}

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

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

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

Continua genérico :wink:

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

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.

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:

public class Usuario{ public String retornaSenha(){ ...criptografa a senha ...retorna a senha } }

public class CaixaEletronico{ public boolean autentica(usuario.retornaSenha){...} }

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

[quote=fzampa]
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 ;)[/quote]

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

[quote=fzampa]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 ;)[/quote]

Nossa, isso da uma quantidade de if enorme nao?

:shock:

[quote=Rafael Nunes]
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()?[/quote]

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

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

[quote=pcalcado]
Entre a apresentação e a persistência fica sua camada de negócios, use ela ;)[/quote]

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?

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

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

class Usuario
{
   private String nome;
   private String senha;

   // getters and setters 
}

classe Login
{
    public void autenticar(Usuario usuario) throws RegraException
    {
       // regra de negocios
      /// o error vai em forma de execption

    }
}

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 :slight_smile:

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

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…

[quote=jprogrammer]Eu acho que os javabeans devem ser usados para representar as entidades em niveis granulares.
ex:

...

classe Login
{
    public void autenticar(Usuario usuario) throws RegraException
    {
       // regra de negocios
      /// o error vai em forma de execption

    }
}

[/quote]

Ok, mas login não deveria ser um método? Um “login” é uma entidade?

Questão bem subjetiva essa. Eu te garanto que em ASp, VB, COBOL, BASIC… vais er bem funcional também. A questão é: OO vale a pena? Achoq eu então isso dá outro tópico…

[quote=fzampa]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. :([/quote]

Se tu fosse fazer aqueles testezinho de OO onde nao se pode usar if tu taria morto neh. :wink:

Por que nao tratar estes erros na camanda de modelo de maneira adequada?

]['s

opa :!:

Então a camada de negócios é tudo aquilo que vc tem entre a apresentação e o armazenamento… tranquilo isso. Se vc faz assim ou assado na regra de negócios depende do padrão que usa, né? Mas era justamente dentro da regra de negócios que eu queria ter uma idéia de uma boa implementação entende?? Queria saber como fazer aplicação da OO ali dentro.

Eu sei que vc vai me mandar ler um livro ou googlar, tudo bem eu vou, mas antes eu gostaria de saber o básico disso, pra nao ler bobagem e sair mudando os sistemas tirando 6 e colocando meia dúzia… :thumbup:

[quote=fabgp2001]
Por que nao tratar estes erros na camanda de modelo de maneira adequada?

]['s[/quote]

Talvez por que eu nao saiba! 8)

Mas é isso que estou tentando fazer aqui… aprender… Como seria a maneira adequada?

Sem um exemplo completo fica difícil, Felipe.

Realment eos livros vão te ensinar a modelar os aspectos do seu problema como objetos, você vai ter usuários, cartões de crédito, vendas, estoques, grupos… tudo como objetos de negócio.

A camada de apresentação vai receber estímulos dos usuários e vai passar estes para a APIda camada de negócios, que vai fazer as operações nos objetos de acordo com o estímulo. Se for necessário, essa alteraçãod eve disparar uma interação com a camada de persistência, para que atualize o SGBD/XML/PQP de acordo com o estado atual dos objetos.