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 pacoteVocê 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?