Coment�rios inline em azul
Danilo Luiz Rheinheimer <[EMAIL PROTECTED]> wrote:
Ola,
Estou pensando em como fazer a arquitetura de uma aplicacao que
estou fazendo. Esta aplicacao vai ser acessada via browser e usar EJB
para implementacao em principio.
Fiz varios testes com Entity beans e assim por diante e nao fiquei
muito satisfeito. Entao lendo no TheServerSide olhei este artigo que
tem algo semelhante ao que estou pensando fazer :
http://www2.theserverside.com/home/thread.jsp?thread_id=16115&article_count=12
A arquitetura que estou pensando e um pouco diferente da que esta no
artigo mas possui a mesma ideia central.
Seria o seguinte :
- Classes persistentes implementadas usando uma tecnologia de
persistencia com o Hibernate (http://hibernate.sf.net). Poderia ser
JDO ou alguma outra. Mas sem entity beans.
MAIKO: Na minha opniao, JDO ainda n�o est� suficiente maduro para uso - falta muuuuito ainda, apesar de ser uma boa id�ia. Nao conhe�o o hibernate, mas no caso seria at� melhor usar Entity Beans com BMP. Apesar de dar mais trabalho pra codificar, voc� tem mais recursos que com CMP que, na minha opni�o, ainda falta evoluir bastante. No meu caso eu uso como frameworks J2EE e de persist�ncia o BC4J e/ou o TopLink, ambos da Oracle, dependendo do projeto e do cliente. No caso do uso do TopLink, fica vi�vel o uso de CMP em qualquer container J2EE com qualquer BD. No caso do BC4J fica vi�vel o uso de BMP em qualquer container J2EE e de quebra voc� ganha todos os J2EE design patterns implementados e mais alguns que a Sun ainda nao catalogou.
- A logica de negocios seria implementada em classes java "normais"
(nao session beans ou coisas assim). Seriam as tais classes POJO (Plain
Old Java Objects) faladas no artigo do TSS.
- Para acesso remoto (da camada WEB) seriam criados session beans
que acessariam camada POJO. Minha ideia e ter uma correspondencia 1
para 1 nisso. Ou seja cada classe POJO teria um session bean
correspondente.
MAIKO: Talvez o melhor seja um Session Fa�ade onde o Session Bean encapsula N classes "POJO". Mas vai depender da sua aplicacao. Geralmente eu implemento um SessionBean por Use Case, mas nao eh uma regra rigida.
Vantagens desta ideia :
- facilidade de desenvolvimento. Grande parte do desenvolvimento da
aplicacao se refere a criar as classes persistentes e a logica da
aplicacao. Neste caso as classes do Hibernate e as classes POJO. Note
que este desenvolvimento pode ser feito sem usar um servidor de
aplicacoes.
MAIKO: Desenvolver persistencia nao eh algo tao simples quanto voce imagina ;-) . O desenvolvimento desta camada de persistencia sem um framework pode arrastar o seu tempo de desenvolvimento para um buraco negro se vc nao tiver uma boa especificacao e definicao de escopo. Procure nao reinventar a roda e usar um pouco da infraestrutura do EJB e frameworks sempre que possivel. Ah, e quanto ao servidor de aplicacoes, nao necessariamente voce precisa ficar fazendo deployment pra um - pelo menos no JDev9i eu soh preciso fazer um "right-click > run" e a minha aplicacao vai rodar no container J2EE "embutido" na propria IDE.
- facilidade de testes. Neste caso falo de testes automatizados como
JUnit. Como consequencia de nao ter necessidade de nao ter um servidor
de aplicacoes rodando estes testes sao muito simplificados.
MAIKO: Bom, eu uso o JUnit de dentro do JDev9i. ;-). Qual o problema de fazer testes integrados remotos?Mais uma coisa: Teste SEMPRE a sua aplica��o em um ambiente (SO, app server, etc) com os mesmos produtos/vers�es que ser�o utilizadas em produ��o. Este � um dos 10 grandes perigos ao se desenvolver aplica��es J2EE:
http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html
- Isso e que eu queria saber. Existe algum problema em desenvolver o
sistema desta forma ? O que isso vai afetar ? O que eu perderia em
relacao a uma aplicacao EJB mais "tradicional" (session beans
acessando entity beans) ?
MAIKO: Veja os coment�rios acima ;-)
---------------------------------------------------------------------
Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED]
Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
Yahoo! GeoCities
Tudo para criar o seu site: ferramentas f�ceis de usar, espa�o de sobra e acess�rios.
