eu também tinha essa dúvida, após um projeto que participei com o Regis (SERPRO), isso ficou mais claro pelo que o Regis falava. Para mim hoje poucas coisas (ou nenhuma) justifcam o uso de mais de um managed bean por página, um managed bean pertence a uma única página e a página a seu managed bean.
Tenho uma aplicação de BI onde existe uma consulta que se pode fazer vários detalhamentos… basicamente ela vai descendo o nível pra ir especificando a informação. Ex: Consulta de Classificação (tipo um Ranking) da pontuação é detalhada para a consulta de indicadores (pontos pra cada indicador que geraram a pontuação final), depois detalhando para os eventos (cada indicador tem vários eventos que juntos geram a pontuação do indicador) indo por fim aos dados de produção (apenas registros que com uma lógica aplicada, geraram os pontos dos eventos).
Hoje dentro dos 3 primeiros MBs eu tenho um método que chama o próximo MB da hierarquia, setando os parametros para detalhar.
Se usasse apenas um facilitaria, pois estaria tudo ali e evitaria ficar chamando outros MBs, mas seria certo ?
Rafael, acha que é válido criar managed-beans mais que o necessário apenas para tentar deixar sua estrutura mais organizada?
Muitas coisas que fazemos acabam sendo feitas por herança de experiências anteriores a capacidade deve haver espaço para auto-crítica, fugindo da mesmice: “Sempre fiz assim e deu certo!” pensar em novas soluções nos leva a evolução.
E se um managed-bean pertencesse apenas a uma determinada entidade (modelo), não seria o mais correto.
Eu que estou agora voltando no tempo e trabalhando action-based, entendi bem melhor como trabalhar com MB.
Eu fiquei com uma dúvida, quando voce diz apenas “um” managedbean? Voce quer dizer apenas um por pagina? Ou por aplicação? Ou ainda quem sabe por regra de negocio/funcionalidade??
Vejo os managedBeans muito ‘orientado a funções’ apenas por acessarem diretamente as páginas (visão).
Pessoal, é simples: Para cada arquivo [*.jsf, *.jsp, *.xhtml], devemos ter um – e apenas um – managed bean. O que acontece: cada página tem seu comportamento, e este comportamento é definido por um managed bean. Ele existe para não poluirmos nossa página com EL’s, tags cheias de comportamento. Caso tenhamos que manter estado da tela, quem sabe sobre o estado é a instância do managed bean. É ele o responsável por manter um escopo de conversação. Por isso, cada recurso web deveria estar associado a um único managed bean. Não faz sentido, e fica poluído, termos diversos managed beans associados a um recurso. Em um projeto grande perdemos o controle (e eu já vi isso várias vezes). A definição de como trabalhar com managed beans também depende das necessidades e de outras definições arquiteturais. Particularmente, eu não aceito o uso de ‘scope’ session em managed beans. Isso é algo raro de acontecer. O problema é que o JSF 1 não provê maneira simples de manter estado de managed beans com escopo de requisição no servidor. A solução acaba sendo recorrer a componentes de bibliotecas alternativas: (t:saveState, a4j:keepAlive, …). Porém, ambos se comportam de forma diferente, e a maioria dos desenvolvedores que fazem uso deles, não sabem como realmente funcionam. Vou parar por aqui, mas tem muito mais pontos a se considerar.
Não há uma regra sobre quantos managed beans devemos implementar para resolver um problema. Como disse no post, hoje em dia eu ainda tenho minhas dúvidas sobre a necessidade de termos mais que um managed bean por tarefa/funcionalidade/UC. Mas ainda não descarto que em certos cenários isso pode fazer sentido.
Ter um managed bean responsável pela navegação faz sentido quando nos utilizamos de uma abordagem com grande uso de AJAX e baseada em “navegação orientada a estados”. O que é comumente visto em sistema coorporativos (mesmo achando que JSF não seja o ideal fora dessa realidade).
JSF é um framework literalmente “core”. Ele foi concebido para ser estendido, o seu uso isolado beira a INUTILIDADE. Trabalhar com JSF sem frameworks e componentes auxiliares para estende-lo ou flexibiliza-lo é inviável no mundo real. Eu tenho um post em draft sobre o assunto, em breve, se a coragem e o tempo permitir, eu devo estar postando algo.
Realmente o uso isolado de JSF é inútil. Porém, sua extensão requer cuidados. A empresa onde trabalho hoje foi cobaia de experimentos do querido Urubatan na criação do Spring Annotations, framework já removido de todas aplicações da empresa atualmente. Uma boa configuração com o Spring atual, facelets, e [Richfaces, Tomahawk] atende diversas necessidades. Pro cliente que quiser pagar, temos o renovado ADF. Mas reinventar a roda não vale a pena. Eu, particularmente, acredito que apenas o NavigationHandler exige uma implementação na versão 1 do JSF.
É possível utilizar Entitis do JPA como beans do jsf? ( eu li que não é possível/recomendávelem uma aplicação onde se utilize apenas JSF, Richfaces e JPA (meu caso) por isso nunca tentei, mas, o Jboss Seam permite fazer isso sem problemas, certo? ).