JSF2 - apoiado por EJB ou ManagedBean?

Question

Como eu estou aprendendo JSF2, eu percebi que não tenho a certeza que os componentes de apoio deve ser. Do ponto de vista do design, o que é a diferença entre EJBs e @ManagedBeans?

No final, eu vou usar JPA, de modo EJB é uma escolha natural para a camada de negócios. É uma boa prática a utilização EJB diretamente de JSF (como explicado aqui )?

No momento, eu estou inclinado a usar @ManagedBeans para componentes que não precisam de acesso a camada de negócios (por exemplo, ver ajudantes) ou lidar com dados de solicitação / sessão. Para outros fins, por exemplo listando algo em uma grade, eu iria diretamente EJB acesso.

Este é um bom design? Devo usar @ManagedBeans para todos os beans de apoio em prol da separação da camada limpo, mesmo que em alguns casos, eles só delegar EJB?

Answer 1

Uma pergunta muito válida, mas eu acho que a resposta depende da "rigidez" da abordagem para o seu projeto. Há de fato um pouco de redundância entre JSF bean de apoio e EJB tanto como implementar alguma lógica de negócios.

Em um ideal uso de JSF apresenta com converters, rendered, validator, etc. o bean de apoio poderia realmente ser código de lógica de negócio limpo. Mas, na prática alguma lógica de apresentação relacionada frequentemente vaza na mesma.

Esta lógica de apresentação relacionada devem, idealmente, não estar em EJB. Esta lógica relacionada à apresentação pode depender do pacote de rostos, mas não necessário. É o que que o tornam apresentação-relacionado ou não.

Um modelo de componente unificado tem algumas vantagens embora. E é a abordagem adoptada pela Seam e Spring . Em ambos os casos, componente de negócios com a transação declarativa, etc. pode ser usado diretamente em JSF (não Primavera não usar EJB, mas fornecer um modelo similar). EJB purista iria, contudo, dizer que você deve dissociar os dois.

Então, para mim, é em última análise, uma questão de gosto e tamanho do projeto. Posso imaginar que para um projeto pequeno / médio usando EJB em JSF fina funciona. Para maior projecto se este rigor é crítica, certifique-se de não estragar as camadas.

Answer 2

Em Java EE 6 haja alguma sobreposição entre os vários beans gerenciados: JSF managed beans (@ManagedBean), CDI managed beans (@Named) e feijão EJB (@Stateless, @Statefull, @Singleton)

.

Na camada de vista, não vejo qualquer vantagem especial para furar com @ManagedBean. O CDI variante @Named parece ser capaz de fazer o mesmo e mais, por exemplo, fornecer-lhe acesso ao escopo de conversão.

O pensamento atual parece ser que modelo de componentes, eventualmente, o EJB também vai ser adaptado como um conjunto de anotações CDI. Especialmente especialista membro do grupo Reza Rahman frequentemente aponta para isso. Veja por exemplo Injeção Dependência em Java EE 6 - Parte 1

Por enquanto, isso não aconteceu, então feijão EJB permanecem o melhor lugar para colocar a lógica de negócios, especialmente quando JPA é usado para persistência.

No entanto, com ou sem CDI irá obter os recursos do EJB, IMHO ainda é uma prática recomendada usar um feijão separado para o conceito "backing bean" e um feijão separado para a "lógica de negócios".

O bean de apoio pode ser muito fino, contendo apenas algumas referências a objetos e serviços (EJBs) modelo. Métodos de ação do bean de apoio pode delegar quase diretamente para os serviços, mas o seu valor acrescentado está em fornecer o usuário com feedback (adicionando FacesMessages sobre o sucesso ou fracasso) e fazer modificações UI pequenas (por exemplo, estabelecendo um boolean como falsa que mostrava algum diálogo) .

Os serviços (de lógica de negócios) não deve saber nada sobre qualquer apresentação particular. Eles devem ser igualmente bem utilizável a partir de grãos JSF apoio, JAX-RS, Servlets, independentes Java SE clientes remotos ou qualquer outra coisa.

Mesmo se todos os grãos se tornaria feijão CDI, então isso não muda essa divisão básica de responsabilidade.

Answer 3

Interessante artigo, não sabia sobre isso. No entanto, para mim este artigo cheira mais como um discurso retórico para a JSF managed beans. Também tight-casais EJB com JSF. É talvez interessante em aplicações pequenas (pessoais), mas provavelmente não em aplicações SOA do mundo real onde você gostaria de ter controle total sobre o EJB foi atendido.

Quanto ao qual usar para o que, eu apenas cumpri-@ManagedBean para denotar um modelo JSF --que está ligado a um ou mais específicos vistas JSF. Você pode perfeitamente usar @EJBs para não-JSF lógica de negócios específica e / ou datamodels. Você pode injetar @EJBs em um modelo JSF e delegá-la em métodos de ação e talvez também getters / setters, mas você não deve fazer o contrário, ou seja, não definir o modelo de JSF em uma @EJB, isso leva a acoplamento forte e faria @EJBs inutilizável fora do contexto JSF. Como agora, a sua sons de design bom, contanto que você assistir a não importação qualquer coisa de pacote javax.faces na classe @EJB.

Answer 4

Ao chamar EJB do seu XHTML, você está introduzindo apertado acoplamento entre a escolha de implementação na vista e negócios camadas.

Se você usar um bean gerenciado para chamar um EJB, [ou até mesmo, colocar em um delegado de negócios], você será capaz de mudar a sua camada de negócios completamente a Primavera sem afetar a camada de visão (XHTML).

É tecnicamente possível, e muito fácil para você (JSR 299) ser capaz de usar EJB como seu bean gerenciado, e isso é provavelmente o que esses fornecedores quero que você faça - get colados aos detalhes. Mas se isso é uma coisa correta a fazer? -. Não