Há pouco iniciei uns estudos sobre a utilização do JBoss pra um novo projeto
e a combinação até então seria JSF (Primefaces) + EJB 3.1 no JBoss, pra mim estava tudo ok.
Daí vi muita gente falando sobre o CDI.
Qual a vantagem real em utiliza-lo?
(Além de poder usar os Beans diretamente no JSF, isso pra mim n faria muita diferença)
E outra, no Eclipse tem a opção de CDI Web Project, isso quer dizer que posso ter um projeto
CDI sem a utilização do Seam, pois tinha lido em algum lugar q um estaria atrelado ao outro.
Então, desta forma, n vjo vantagem, o que pensei foi, caso eu fosse usar, diminuir uma
camada, já que JSF teria acesso direto ao EJB através do CDI (ou estou errado?)
Se estou certo, isso seria possível, correto?
Pagina JSF —> EJB Business(via CDI) ----> EJBFacade.
Pq da outra forma q vc citou mudaria apenas as nomeclaturas?
O CDI é um padrão de injeção de dependências baseado em anotações. Ele é extremamente sofisticado neste sentido e facilita muito a testabilidade da sua aplicação fora do container, além de existirem extensões portáveis disponíveis para uso.
Então, desta forma, n vjo vantagem, o que pensei foi, caso eu fosse usar, diminuir uma
camada, já que JSF teria acesso direto ao EJB através do CDI (ou estou errado?)
Se estou certo, isso seria possível, correto?
Pagina JSF —> EJB Business(via CDI) ----> EJBFacade.
Pq da outra forma q vc citou mudaria apenas as nomeclaturas?[/quote]
Por uma escolha nossa, eu não misturo regras de negócio com regras visuais (tela, exibir ou não botões, validação de campos, etc)… ficaria uma bagunça…
A minha camada Business, é acessada tanto pela tela quanto por webservices e por outros EJBs de outros projetos…
Eu não vejo que CDI ou o SEAM são para economizar trabalho, e sim para organizar, padronizar e dar mais recursos… pra economizar trabalho temos diversas outras linguagens e frameworks que fazem isso sacrificando outras coisas…
Como eu estou estudando ele agora, eu n consegui ver as vantagens ainda.
Uma coisa q li aqui no forum é que é possível fazer testes fora do container,
isso eu achei interessante, apesar de n ter testado nem ter visto algo parecido
ainda.
Mas vou futucar um tikin mais pra v, pois quero iniciar um projeto, que n é
grande mas que pode tomar outras porporções, e tinha pensado na estrutura
algo como vc citou:
Já resolveria até o momento, mas como vjo muita gente falando sobre a arquitetura
com o CDI, achei importante tentar descobrir vantagens.
[QUOTE]
Por uma escolha nossa, eu não misturo regras de negócio com regras visuais (tela, exibir ou não botões, validação de campos, etc)… ficaria uma bagunça…
[/QUOTE]
Mais não é estranho colocar um EJB para cuidar dessas validações de tela?
A pergunta seria!
porque eu necessitaria de trocar o MB por um EJB na camada de aprensentação?
Como eu estou estudando ele agora, eu n consegui ver as vantagens ainda.
Uma coisa q li aqui no forum é que é possível fazer testes fora do container,
isso eu achei interessante, apesar de n ter testado nem ter visto algo parecido
ainda.
Mas vou futucar um tikin mais pra v, pois quero iniciar um projeto, que n é
grande mas que pode tomar outras porporções, e tinha pensado na estrutura
algo como vc citou:
Já resolveria até o momento, mas como vjo muita gente falando sobre a arquitetura
com o CDI, achei importante tentar descobrir vantagens.
[quote=erickfm8][QUOTE]
Por uma escolha nossa, eu não misturo regras de negócio com regras visuais (tela, exibir ou não botões, validação de campos, etc)… ficaria uma bagunça…
[/QUOTE]
Mais não é estranho colocar um EJB para cuidar dessas validações de tela?
A pergunta seria!
porque eu necessitaria de trocar o MB por um EJB na camada de aprensentação?[/quote]
Eu que me confundi com os nomes… acho que quando vc troca um MB por uma classe CDI (anotada com @named), se chama Webbean… não é EJB mesmo…
[quote]
Mais não é estranho colocar um EJB para cuidar dessas validações de tela?
A pergunta seria!
porque eu necessitaria de trocar o MB por um EJB na camada de aprensentação?[/quote]
Realmente, ficaria ums estrutura desengonçada, acho que o lugar do EJB é cuidar do "business"
mesmo, a camada MB ou WebBean (como li aqui) deve focar mais o “Controller”, vai virando camada
feito a p… no sistema, mas de outra forma fica meio zoneado mesmo, e pelo q vi, se fosse usar o EJB
com anotação @Named, perde-se um pouco em relação à flexibilidade do escopo, então, volto ao que
Kleins havia dito:
Melhor assim, seguir o mesmo esqueleto do ManagedBean com a flexibilidade do CDI.
Acho q é isso, mas quaisquer outras vantagens serão bem vindas ao post.
E galera, “vamo” melhorar o nosso “portuga”, tem coisa meio osso aqui rs.
Na verdade anotar um bean como @Named não o torna um EJB, somente um bean gerenciado belo CDI. EJB’s são anotados com @Stateless ou @Statefull (ou @MessageDriven para beans JMS).
Diferença?Beans CDI não tem suporte a transação ou chamadas remotas por exemplo.
Eu andei fazendo uns testes e gosto de fazer assim:
Quanto às vantagens do CDI, ele tem recursos interessantes, como processamento de eventos assíncronos, qualificadores, “produtores”…
