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

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

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

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.

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.

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.

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?