EJB's e JDBC

Ola,

Qual o motivo de usar EJBs em primeiro lugar?

Humm
Não quero usar EJB’s pq toda a gente usa!!!
O cenário é o seguinte: um user no portal da empresa acede à aplicação via web browser e solicita o relatorio diario. Os campos desse realtorio são preenchidos com valores que estão na base de dados. Então pensei em EJB’s para lidar com essa parte das queries. E JSP’s+Servlets pra parte de apresentação.
Está mal??
Sou muito verde e nunca fiz uma aplicação J2EE toda e de raiz…
Toda a ajuda é bem vinda.
Cláudia

Recomedaram-me usar Session Beans do tipo Stateless. Que acham??
Correto, a menos que vc precise conservar o estado de seu session durante várias requisições.

E a ligação JDBC fica dentro de um bean??
Não, Vc vai criar um datasource e neste vai configurar pool de conexões e as configurações padrão para acesso ao banco como url, password, …

Já ouvi falar em connection pool e DAO?? Que é ? Preciso disso???
Como falei o pool de conexões vc configura no datasource. DAO basicamente é uma camada que vc utiliza para separar o sql e ou recursos de manipulação relacionados a sua fonte de dados.

Preciso disso???
As camadas e padrões são apenas sugeridos para facilitar manutenção e desenvolvimento, mas, fica a seu criteria. Eu recomendo utilizar uma camada de DAO.

Obs.:

• Pesquise no forum que vc vai encontrar informações sobre DAO.
• Sobre datasource o jbos tem exemplos em $JBOSS_HOME/docs/examples/jca/

Quantos beans vou precisar???
Depende de seu negócio / caso de uso. Ai vc vai ter que definir

"neste meu ceú nublado"
Putz, já faz 3 semanas que chove direto.

flw

Pelo que vocÊ colocou sobre o projeto vc não precisa de EJB!

É mais sensato você usar Servlets que também é J2EE! Não caia nesta história de usar EJB pq todo mundo acha ele bonitinho e engraçadinho!

Se você quer aproveitar esta oportunidade neste projeto para aprender algo a mais, então opte por um framework como o hibernate para fazer a persistência. DAO também é interessante e imprecindível em vários projetos, acho que vc deveria dar uma olhada neste padrão!

Se te obrigarem a usar os Session Beans, eu no seu lugar tentaria negociar a possibilidade de usar RMI!

Veja bém, JBOSS é um servidor muito parrancudo, enquanto sua aplicação é muito simples. Vc tá matando uma mosca com um canhão! O Jetty ou Tomcat com certeza está de bom tamanho! Além de agilizar o processo de desenvolvimento, é mais fácil (em minha opinião) de se aprender!

O hibernate num resolve seu problema? Usar EJBs só por esse motivo não se justifica, fora q o aprendizado eh mais lento.
Acho muito mais simples vc desenvolver uma aplicação com hibernate, por ser bem mais produtivo e fácil de aprender.

Aqui em Portugal não chove há muito e fala-se de SECA!!!
Estamos em pleno Verão e céu azul!

Para relatórioa pesados, JDBC + DAO ou ferramentas específicas ajudam (busque no fórum sorbe ireport, jasperreports, essas coisas).

O único bom motivo para o uso de EJB que eu veria era se você precisasse de clientes remotos, não aprece ser o caso.

Servlets+POJOs+DAOs dão pro gasto.

Se precisar de algo mais complexo, veja o Spring Framework.

[]s

Creio que os relatórios são pesados pois terão de apresentar gráficos.

Clientes remotos? O servidor fica no local X e a empresa possui várias filiais em outros locais, embora na mesma cidade… são remotos não são??

Vejo que vocês fogem a todo o custo de EJB’s…

Até fico daquilo em que me estou a meter :roll:

Aplicações clientes, digo.

Um browser não é um cliente remoto nesse cotnexto.

Uma maquina onde ficam os EJBs e uma interface web nao possui cliente remoto. Servlets já costumam ser suficientes.

Uma maquina com os EJBs, outra maquina com a itnerface web acessando esses EJBs, eh cliente remoto. Neste caso EJB (Stateless Session beans) pode ser uma boa saída.

Me corrijam se eu estiver errado!

Claudia, o cliente vai acessar aplicação usando swing ou brownser?

Se for brownser, acho que seria interessante vc usar Session Beans, assim como sugeriu o Philip.

Mas se o cliente for swing, não vejo necessidade! Se vc usar servlets ou mesmo RMI, basta sua aplicação servidora passar os dados para a aplicação cliente, e fica de total responsabilidade da view criar os relatórios e os gráficos!

Agora também estou em dúvidas… Dependendo do tamanho da aplicação, RMI ou Servlet não vale mais a pena do que Session Beans?

Abraços!
Thiago

Thiago não me digas q tens dúvidas porque assim até me desanimas :roll:
Eu kero que os empregados da empresa tenham um link no portal da empresa que abra uma página Web onde poderão ver os relatorios e graficos. Portanto é via browser. É um cliente WEB.
Julgo que qdo falas em swing falas em cliente Java (application client), certo?

É, quando falo em swing estou falando de uma aplicação desktop que fica se comunicando com um servidor remoto!

O interessante no caso deste tipo de cliente é que o processamento responsável por gerar os gráficos e o relatório ficariam no cliente, e não no servidor! Mas quando é brownser é o servidor que irá processar e gerar os gráficos!

Bom, eu não sou o mais indicado para indicar o que fazer. De acordo com muitas discussões que já houveram neste fórum o jeito é vc usar o session bean somente para delegar as chamadas remotas para suas classes de negócio!

view --> session bean --> camada de negócio --> persistência

ou

view --> session bean --> façade --> camada de negócio --> persistência

Abraços!
Thiago

Claudia,

Na minha opinião, pela simplicidade da sua aplicação, seria mto produtivo o uso de servlets carregando relatórios gerados pelo JasperReports. Vc não precisaria de nenhum framework de persistência pois no próprio jrxml gerado pelo JasperReport existe a query que deve ser executada para gerar aquele relatório … Você só chama o servlet passando os paramentros que a query necessita.

Já estive em um projeto onde optamos por este uso, e obtivemos muito sucesso, inclusive aprendizado de uma ferramenta q é mto requisitada no mercado para geração de relatórios e gráficos …

Abraço e boa sorte.

Ps.: Eu possuo alguns tutoriais sobre o JasperReports, JFreeChart e IReports. Se precisar é só pedir.