Ir para o conteúdo
  • Revista PROGRAMAR: Já está disponível a edição #60 da revista programar. Faz já o download aqui!

Baderous

JSF 2.0 + EJBs + Backing Beans + MVC-2

Mensagens Recomendadas

Baderous

Tenho de desenvolver uma aplicação Web em JSF 2.0, mas estou a ter um bocado de dificuldade em perceber como se organizam os beans EJB que vão suportar a aplicação, de modo a cumprir o padrão MVC-2 do JSF e também de modo a efectuar uma correcta divisão das camadas da aplicação.

Tenho andado a ler montes de páginas e opiniões pela net e ainda não consegui chegar a um consenso, se bem que já recolhi uma série de ideias. De entre as páginas que li, aquelas a que dei mais atenção foram as seguintes:

http://www.oracle.com/technology/tech/java/newsletter/articles/introjsf/index.html

http://www.java-samples.com/showtutorial.php?tutorialid=350

http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSFIntro8.html

http://www.guj.com.br/posts/list/72237.java

http://www.ibm.com/developerworks/library/j-jsf1/

http://stackoverflow.com/questions/746047/jsf-backing-bean-structure-best-practices

http://blog.icefaces.org/blojsom/blog/default/2009/04/23/Making-distinctions-between-different-kinds-of-JSF-managed-beans/

Também vi esta, mas não vou ter tempo para estar a ler tudo...

Destas (sei que algumas ainda se referem ao JSF 1.2), destaco as 2 últimas que, juntamente com tudo o resto que li, me permitiram chegar a 2 ideias quanto aos beans:

1) os Backing Beans fazem parte do Controller (do MVC-2), possuem métodos do tipo verificaLogin() e têm como variáveis de instância POJOs (que apenas têm variáveis + gets/sets, ou seja, são os Entity Beans (EJBs)). Esta é a versão suportada pelo artigo do IceFaces (embora esse artigo ainda use o JSF 1.2, mas penso que isso não tem influência);

2) os Backing Beans são Entity Beans (EJBs) só com propriedades + gets/sets (se necessário, têm apenas a lógica associada à apresentação da página). Toda a lógica de negócio fica nos Session Beans e etc. Esta versão é suportada por um dos posts do Stack Overflow.

Eu sei que os Entity Beans são as entidades do modelo de domínio que vão ser persistidas (no meu caso, vou usar Hibernate) e que possuem operações do tipo CRUD e que os Session Beans são os beans que possuem a lógica de negócio.

Agora, perante isto, eu não consigo saber qual é que está correcta (se é que alguma delas está correcta), porque não consigo, em nenhuma das 2 ideias, perceber onde entram aqueles diversos tipos de beans introduzidos pelo padrão MVC-2 que são referidos no artigo do IceFaces (lá diz que são diferentes tipos POJOs geridos pelo JSF - os managed beans), e porque, apesar de ver aqui a ideia comum dos Entity Beans, não consigo ver onde entram os Session Beans (está-me a fazer confusão: os Session Beans são beans do Controller os os Entity Beans são do Model? Se os Entity Beans são os POJOs geridos pelo JSF, como podem eles ter apenas os gets+sets? Só se os Entity Beans do EJB forem os Model Managed Beans referido no IceFaces...). Pior ainda, não consigo fazer a ligação entre os beans da tecnologia EJB e os beans do padrão MVC-2.

Portanto, gostaria que alguém com experiência no desenvolvimento Web com Java e EJB me esclarecesse sobre as melhores práticas, como se devem construir correctamente os beans, de modo a ter uma aplicação que siga o padrão MVC-2 do JSF 2.0 e que promova a separação de camadas, porque eu penso ter o conhecimento sobre EJB, JSF e MVC necessário para entender, só que não consigo é encontrar algo que me diga como estruturar a aplicação em termos dos beans.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
brunoais

Eu n sei resolver o problema...


"[Os jovens da actual geração]não lêem porque não envolve um telecomando que dê para mirar e atirar, não falam porque a trapalhice é rainha e o calão é rei" autor: thoga31

Life is a genetically transmitted disease, induced by sex, with death rate of 100%.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Knitter

Eu uso os Beans segundo a abordagem 2. São apenas objectos simples com gets/sets. No entanto, não há uma forma correcta de implementar isso, podes tentar seguir o padrão, e organizas as camadas consoante o padrão e as regras base do mesmo, mas como pudeste ver, cada um interpreta o padrão como bem entende. Pessoalmente acho mais simples considerar os BB como EJBs, mas apenas porque isso me pareceu a forma mais eficiente de implementar o padrão.

Não uso JSF há algum tempo, e não conheço as modificações da versão 2.0, apenas usei a 1.2, mas não acredito que a implementação esteja tão dependente da tecnologia JSF.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Baderous

Eu também falei hoje com um professor da área da HCI, e falei-lhe sobre os tais tipos de beans que tinha visto e tal (não dei uma explicação tão pormenorizada, falei-lhe dos Entity e Session Beans ao nível da camada de negócio e dos diferentes tipos de Managed Beans ao nível da camada de apresentação), e o que ele me disse é que os Backing Beans são os Entity Beans, e que depois se podem usar estes mesmos para trabalhar a(s) página(s), isto é, para além dos atributos do modelo de negócio que esses beans têm, também têm coisas tipo texto de labels e etc, ou seja, corresponde à minha 2ª ideia:

2) os Backing Beans são Entity Beans (EJBs) só com propriedades + gets/sets (se necessário, têm apenas a lógica associada à apresentação da página). Toda a lógica de negócio fica nos Session Beans e etc. Esta versão é suportada por um dos posts do Stack Overflow.

Ele depois também começou a falar de Seam e a embrulhar para lá com a abordagem do Seam que liga todas as camadas (Apresentação, Negócio e Dados), e pôs-se para lá a falar de persistência, mas não me convenceu muito a explicação dele. Isto porque se os Entity Beans:

- correspondem às entidades do modelo de domínio

- vão ser persistidos em base de dados, via Hibernate

então não faz sentido que eles tenham como atributos "extra" as tais labels e etc, 1º porque isso não faz parte da entidade do modelo de domínio (não faz sentido eu dizer "Tenho uma classe Utilizador que tem um nome, email e uma label de boas-vindas..."), e 2º porque, sendo persistidos via Hibernate (e tendo as tabelas a estrutura necessária para acarretar apenas os atributos do domínio - no caso que indiquei do Utilizador, seria o nome e email), parece-me que fico perante 2 situações possíveis:

1) ou dá barraco porque a tabela da entidade Utilizador não tem campo para guardar a tal label;

2) ou então vejo-me obrigado a criar primeiramente as entidades do domínio, de seguida gerar toda a camada de persistência via Hibernate, e só então depois, partir para o desenvolvimento da interface, adicionando às entidades (os Entity Beans), coisas como labels e etc, que não vão ser persistidas.

Sinceramente, é uma coisa na qual estou a remoer. Quanto à camada de negócio, não há dúvidas nenhumas, existem os Entity Beans e os Session Beans (e se necessário os Message Driven Beans). Agora a celeuma surge quando entramos na parte da apresentação em que sou confrontado com os tais diversos tipos de beans (indicados na página do IceFaces), os quais não consigo ligar aos beans da camada de negócio. Até agora a única ligação plausível que encontrei foi os Model-Beans serem os Entity Beans, e depois existiam todos aqueles beans indicados no artigo do IceFaces na camada de apresentação, sendo que na camada de negócio continuavam a existir os Session Beans, ou seja, os Model-Beans fariam a ponte.

Vou ver se ainda esta semana falo com outro professor mais ligado à área do JEE a ver o que ele diz.

Se alguém puder esclarecer este assunto, agradecia.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!

Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.

Entrar Agora

×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.