Caros,
Aqui na empresa temos uma discussão em torno de técnicas e melhores práticas para a criação e gerenciamento de ManagedBeans. Não sei se este assunto já foi bem discutido em outras threads, mas ai vai: na opinião de vocês, qual a maneira mais eficiente de tratar a criação de um ManagedBean? Por exemplo: (i) um MB por xhtml (–), (ii) um MB por entidade, (iii) um um MB por conceito de domínio…
Caso conheçam algum blog legal sobre o assunto, também é bem vindo.
Amigo, ao meu ver, a criação do Managed Bean deve ser um por entidade. Quando se tiver uma situação mais especifica, se cria outro ManagedBean. Participo de projetos grandes e de grandes empresas, e todas adotam essa metodologia, o que realmente vem dando certo, pois até quanod alguem vai dar alguma manutenção no sistema, se acha mais facil!
Olá darksteel3000, em tais projetos que faz parte, existe também uma tendência a se usar o escopo (View, Session, Application, …)?
Sim sim, amigo, existe sim. Nós utilizamos só o de Request e o Session. Request para as paginas, que não requerem de passar parametros ou valores para outras telas seguintes, e o Session para ficar fazendo esse trabalho de guardar valores para as proximas operações. O ViewScoped, ainda não vimos utilidade para ele!
Prefiro a abordagem de criar um maneged bean por caso de uso.
Quando se tem uma tela de consulta e uma de cadastro/edição, qual a melhor forma de fazer sem utilizar escopo de sessão? Colocar a tela de consulta no mesmo xhtml do cadastro e utilizar o renderer para exibir e ocultar, ou utilizar xhtml separados, porém utilizar flash para transferir o bean da consulta para edição.Existe outra forma de fazer isso no MB?
Amigo, caso suas telas tanto de consulta, quanto a de edição estejam apontando no mesmo MB, então poderás utilizar o Request. Aqui na empresa utilizamos o request e ele faz todo o trabalho. Agora caso vc tenha uma tela de consulta que pertence a um MB e quando cliques em alguma opção que pertence a outro MB, o que tem de ir ai é o Session mesmo. Ou até mesmo o View !
Também sigo mais a linha do caso de uso por MB. Mas não dá pra colocar isso como regra.
Prefiro colocar no mesmo xhtml (na verdade separo e dou um include) e uso o renderer para mostrar ou não. Neste caso utilizo o escopo de View.
Se for usar da outra forma o melhor é utilizar o flash mesmo ou um scope conversation. Só use session se realmente precisar. Já vi muitas aplicações desenvolvidas inteiras utilizando session, assim você mata o servidor.
darksteel3000 como você passa o objeto da tela de consulta para o cadastro com request. Pois será outra instancia do MB… tem como dar um exemplo?
Hoje uso flash para armazenar…mas acho isso meio que “gambiarra”. Acho que deve ter uma forma mais elegante ao qual deixa o código mais limpo.
Obrigado
Amigo, simples simples. Ve so:
Abaixo é o meu codigo do xhtml:
<p:commandButton id="selectButton" icon="ui-icon-search"
action="cliente.manter"
title="Detalhar" ajax="false">
<f:setPropertyActionListener value="#{cliente}"
target="#{clienteBean.cliente}" />
</p:commandButton>
Quando o botão é precionado, coloco nesse setPropertyActionListener o valor que quero jogar na variavel target, e pronto. Nesse caso ele irá para outra tela outro xhtml mas do mesmo managed bean, onde recebo o cliente e nem preciso fazer consulta nenhuma pra exibir os dados dele. Entendeu?
entendi…no seu action…o cliente.manter retorna apenas a pagina de cadastro…não se faz nenhuma ação correto? E a tela de cadastro e consulta não estão no mesmo xhtml
Amigo, esse cliente.manter é o meu mapeamento feito no faces-config.xml; Simplesmente muda de xhtml. Não são no mesmo arquivo xhtml.
ok…não uso o face-config…uso direto…fiz aqui e funcionou…
Estou usando primefaces e a tela de edição é chamada ao selecionar um item do datatable…ai eu tinha que fazer redirecionamento no rowSelectListener…ai coloquei um comandlink para fazer a edição…porém tive que colocar ajax =false para funcionar…
Valew…
Massa. Outra dica que te dou é tipo, vamos supor que antes de chegar na outra tela, tu quiseres carregar outras coisas a parte. Daí mano, c coloca um action listener e manda o parametro para fazer o tal carregamento pelo <f:param> e captura ele no seu metodo que recebe um action event.
Utilizo muito isso, pois quando por exemplo, carrego um cliente, preciso carregar um monte de outras coisas que não tem muita relação ao meu objeto!
minha opinião é a seguinte:
para casos de uso que são praticamente cruds uso um mbean, já o escopo vc tem que pensar o pq usar cada uma e lógico conhecer todas, sou fã da viewScoped, Session use só quando necessário.
outra duvida é … no escopo de request , no caso de edição em outra tela , você terá que carregar todos os dados no form, principalmente o id. E quando eu tenho um bean composto e está informação não é carregada no form. Ex: Cliente tem uma lista de Contas…quando eu persistir esse cliente essas contas estarão como null no cliente.
Como faço nessa situação conforme o darksteel3000 exemplificou?
Opa amigo, podes fazer de varias formas. Vamos supor que a consuta da tua lista la, tu ja tenhas o cliente carregado com as contas, ele vai as contas do cara, senão, tá lembrado daquele <f:param> com o actionListener que te disse?
Com ele poderas colocar um metodo no actionlistener e como todo metodo de actionlistener recebe um evento, nesse evento estará o valor do parametro ( um id por exemplo ), pronto para vc ir no banco e carregar as contas daquele determinado cliente, e setar na lista de contasdo seu MB, daí quando a tela de edição abrir ja vai vir prontinho.