[Resolvido] É possível fechar o encapsulamento com JSF?

Olá pessoal.

Eu gosto muito de JSF, mas uma coisa que não gosto muito é o fato de ter que abrir o encapsulamento da classe, devido ao padrão Java Bean adotado. Eu queria saber se existe alguma maneira de burlar isso, se eu consigo deixar minhas classes bem encapsuladas, a nível de pacote, e mesmo assim, utilizar os recursos do JSF normalmente. Alguém tem alguma idéia pra isso?

Abraços.

Como assim?

classes bem encapsuladas, a nível de pacote

Você quer dizer, não colocar seus métodos getters e setters como public?

Isso. Desculpe se não consegui me expressar bem. Não quero que outras classes consigam alterar o estado de outra classe de outro pacote. Na verdade, eu gostaria que nenhuma classe tivesse esse poder, mas deixar 100% encapsulada é complicado hehe.

Veja se entendi corretamente, você quer que nenhuma classe possa alterar o estado de seus JavaBeans? Qual sua motivação para isso?

Isso mesmo. Eu não quero correr o risco de modelo anêmico. Eu estou pesquisando mas não encontro nada. Acho que deve ser impossível fazer isso.

O problema na verdade é que o EL do JSF, utiliza os metodos getters/setters para obter e setar seus campo, o que você pode fazer é, validar nos seus SET’S os dados que estão sendo passados. Acredito que você esteja lendo alguma coisa sobre o modelo anêmico, acredito que em poucas situação existe a real necessidade de impedir todo tipo de alteração do estado por classes externas.
Se você partir para essa abordagem, acredito que será uma questão de gosto.

Abraço

[quote=guilherme_costa]O problema na verdade é que o EL do JSF, utiliza os metodos getters/setters para obter e setar seus campo, o que você pode fazer é, validar nos seus SET’S os dados que estão sendo passados. Acredito que você esteja lendo alguma coisa sobre o modelo anêmico, acredito que em poucas situação existe a real necessidade de impedir todo tipo de alteração do estado por classes externas.
Se você partir para essa abordagem, acredito que será uma questão de gosto.

Abraço[/quote]

Apenas complementando, pois eu também pensava assim.

Nesse caso é preciso tomar bastante cuidado com o que se quer colocar nos modificadores, pois se for uma lógica custosa de validação isso pode gerar problemas de performance, visto que durante o ciclo de vida do JSF ele realiza várias chamadas aos getter’s e setter’s dos objetos expostos no backbean.

Só para ter uma ideia, coloque um sysout em qualquer um dos set/get do teu backbean (managed bean)

Infelizmente é o tradeoff que o framework impõe na sua escolha…

Galera valeu pelas dicas. Eu achei um artigo que talvez possa matar meu problema, mas eu preciso testar primeiro.

Mas se não der certo, o jeito vai ser se entregar ao JavaBeans mesmo hehe.

Valeu.

Não dá pra fugir dos gets e sets. E para ser justo, isso nem é culpa do JSF, qualquer framework vai precisar manipular os atributos em um objeto, e esses atributos precisam ser acessíveis para leitura e escrita.

Já que tem essa preocupação em manter o modelo livre de gets e sets desnecessários, o que você pode fazer (seja em JSF ou em outro framework) é não usar classes do Modelo como beans do JSF. Crie um pacote diferenciado para conter esses VOs que podem ser considerados simplesmente “armazenadores de valores da view”. No backing-bean você faz a ponte entre Objeto de Domínio e VO da View.

Bom galera, só pra finalizar o assunto. Utilizando o Lombok, eu consegui alcançar o que eu queria. Ele gera os getters e setters em tempo de compilação e assim, funciona lindamente no JSF. Com isso, eu consigo forçar o programador a pensar na hora de criar a classe e não simplesmente “abrir as pernas”.

Confesso que não é a solução que eu gostaria, mas já quebra um galho. Estou testando desde ontem e acho que vai ser muito útil nessa migração do projeto.

Porém, se alguém souber de outra forma, gostaria muito que compartilhasse a experiência.

Obrigado pela ajuda.

Abraços.

Não dá pra fugir dos gets e sets. E para ser justo, isso nem é culpa do JSF, qualquer framework vai precisar manipular os atributos em um objeto, e esses atributos precisam ser acessíveis para leitura e escrita.

Já que tem essa preocupação em manter o modelo livre de gets e sets desnecessários, o que você pode fazer (seja em JSF ou em outro framework) é não usar classes do Modelo como beans do JSF. Crie um pacote diferenciado para conter esses VOs que podem ser considerados simplesmente “armazenadores de valores da view”. No backing-bean você faz a ponte entre Objeto de Domínio e VO da View.

[/quote]

Pois é, eu tinha pensado nisso, mas eu queria evitar isso também hehehe.

Uma opção mais radical seria eliminar totalmente o value-binding, assim o JSF nunca irá acessar atributos dos seus objetos. Ao invés disso, fazer component-binding e obter todos os valores no backing-bean usando component.getValue() (como se estivesse programando Desktop!).

Talvez isso seja trabalhoso e eu particularmente nunca vi ser usado dessa maneira… se quiser faça um pequeno teste para ver se é prático.

[quote=gomesrod]Uma opção mais radical seria eliminar totalmente o value-binding, assim o JSF nunca irá acessar atributos dos seus objetos. Ao invés disso, fazer component-binding e obter todos os valores no backing-bean usando component.getValue() (como se estivesse programando Desktop!).

Talvez isso seja trabalhoso e eu particularmente nunca vi ser usado dessa maneira… se quiser faça um pequeno teste para ver se é prático.[/quote]

Humm, interessante. Vou fazer testes, mas acho que o Lombok já resolve muito o meu problema.

Pilantra, só por curiosidade, oq mudou usando o Lombok? porq ele gera os getters e setters do mesmo jeito, ou seja a classe “não esta encapsulada” como antes, apesar de não ser aparente isso… qual a diferença entre as duas abordagens?