Deixei meus coment�rios entre linhas:
> --- "Maiko A. Rocha" <[EMAIL PROTECTED]> > escreveu: > > > 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. > ---------------------------------------- Uma dica seria encapsular a maior quantidade poss�vel de informa��es nos seus "Value Objects" para dependendo da necessidade de quem o utilizar seja mais tranquilo optar e/ou reescrever DAOs (inclusive para v�rios BD)ou JDO. ------------------------------------------- > > > > - 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. > > > ---------------------------------------- Gosto muito da id�ia de minimizar o uso de EJBs para diminuir o tr�fego de rede e aumentar a reutiliza��o do c�digo caso quem utilizar este framework optar por n�o utilizar EJBs. Uma dica seria rever as patterns Service Locator e Service Activator ---------------------------------------- > > > > > 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 ;-) > > > ---------------------------------------- Pessoalmente acredito que n�o existe a f�rmula perfeita para desenvolvimento de um framework e menos ainda de todo um sistema, todos tem os seus pr�s e contras. Tento seguir ao m�ximo poss�vel as patterns da SUN, pois tem um monte de gente l� que j� pensou em um monte de coisas para facilitar nossa vida. Mas tenho em mente uma coisa: Quem paga � o cliente, e ele quer qualidade (do produto final), prazos curtos e pre�o baixo! N�o adianta inventar uma solu��o linda que n�o atenda esses tr�s requisitos !!! O resto, muitas vezes pouco importa. Estou desenvolvendo uma solu��o parecida para integrar um projeto open-source de um sistema ERP/CRM que pretendo colocar no ar at� o final do ano e como eu acho que vc pode ficar tranquilo. []�s Robson Luis Ferreira [EMAIL PROTECTED] ---------------------------------------- ---------------- > > 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. > > === message truncated === ===== Robson Luis Ferreira [EMAIL PROTECTED] Tel: (11) 9827-6406 _______________________________________________________________________ Yahoo! GeoCities Tudo para criar o seu site: ferramentas f�ceis de usar, espa�o de sobra e acess�rios. http://br.geocities.yahoo.com/ --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
