Fernando, Por J2EE, entendo que voce estah se referindo ao J2SDKEE, a RI da Sun.
Alguns comentarios meus sobre isto: - A RI eh um proof-of-concept da especificacao, ou seja, apenas mostra que ela pode ser implementada e dah algumas dicas aos fabricantes de como interpretar as ambiguidades. Performance estah longe de ser uma preocupacao do pessoal que escreveu a RI. Recomendo o uso de um AppServer "de verdade" para os seus testes, como o JBoss, OpenEJB, Orion, JRun, WebSphere, WebLogic, OracleAS ou outro qualquer, mas, preferencialmente, daquele que sua empresa pretende usar nos projetos. Se voces pensavam em usar a RI, esquecam - a licenca _nao permite_ deployments comerciais. - O seu teste nao levou em conta algo que pode ser uma das grandes vantagens de se usar EJB - o cache do container. O appserver consegue fazer cache das instancias e pode nao repetir a consulta quando esta for feita por mais de um usuario. Refaca o seu teste com o numero de usuarios simultaneos esperado pela sua aplicacao. - Nada impede voce de fazer joins nas suas consultas desde que seu appserver suporte isso... E tambem nada impede voce de usar DAOs/JDBC com Session Beans somente nessa situacao para ganhar performance. Na maioria das vezes uma arquitetura combinada eh a melhor saida. Tente repetir os testes conforme eu falei e nos informe dos resultados. Aih poderemos dar conselhos mais praticos. []s Michael Nascimento Santos Sun Certified Programmer for the Java 2 Platform Sun Certified Programmer for the Java 2 Platform 1.4 Moderador SouJava - www.soujava.org ----- Original Message ----- From: "Fernando Rubbo" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 04, 2002 4:03 PM Subject: RES: [enterprise-list] classes DAO/Value Object O teste que a gente eu fiz fom com o CMP do J2EE e retornou uma quantia de registro media das buscas que deverao ter em todo o sistema... O problema eh que no sistema(atual), existem consultas que retornam em torno de 2500 registros. Se o sistema estiver sendo usado por 200 pessoas e algumas delas estiverem executando consultas como estas(com Entitys), nos achamos que poderia sobrecarregar o servidor... Outro problema que eu encontrei com as Entitys eh, que no nosso sistema a maioria das pesquisas(90%) vao ser com 2 � 5 tabelas relacionadas... e com as entity eu me atrapalhei todo... onde um select resolvia o caso... T+ Fernando PS: ajudou sim... -----Mensagem original----- De: Michael Nascimento Santos [mailto:mister__m@;hotmail.com] Enviada: seg 04/11/2002 15:11 Para: [EMAIL PROTECTED] Cc: Assunto: Re: [enterprise-list] classes DAO/Value Object Fernando, Tenho algumas perguntas basicas sobre os seus testes: A qtde de registros usada nos testes equivale realmente a media de registros que vc terah no seu sistema de verdade? Vc usou CMP ou BMP nos Entity Beans? Qual o container utilizado? Com respeito aos VOs, agora conhecidos como Transfer Objects, o objetivo eh retornar d forma lightweight os dados requeridos. Podem representar dados d mais de uma entidade no seu sistema. Voce pode monta-los diretamente no DAO ou utilizando o pattern Transfer Object Assembler, entre outros. Tem gente q faz TOs com campos public, outros com set e get, outros q geram direto nos entities... O q nao falta sao formas d gerar esses beans. Vc tem q entender o escopo do seu problema - como eu sempre costumo dizer :-) - para saber kal a melhor forma d fazer isto no seu caso especifico. Espero ter ajudado. []s Michael Nascimento Santos Sun Certified Programmer for the Java 2 Platform Sun Certified Programmer for the Java 2 Platform 1.4 Moderador SouJava - www.soujava.org ----- Original Message ----- From: "Fernando Rubbo" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 04, 2002 2:11 PM Subject: RES: [enterprise-list] classes DAO/Value Object Nao sei se os testes que fizemos da para se considerar a risca... mas nos fizemos uma consulta com relacionamento entre tabelas(de uma quantia razoavel de registros) e controlamos o tempo. e fizemos a mesma consulta com o DAO.(Esse teste foi repetido em 2 maquinas diferentes...) o resultado da Entity foi no minimo 2x mais lento que do DAO... Como disse antes... Eu nao conhe�o muito bem a tecnologia e talvez eu tenha feito alguma coisa errada.. nao sei... Outra duvida: Os VO, seriam somente os campos que retornariam da consulta??? somente para transporte dos dados de uma camada para outra????? teria que se fazer um while no resultset e colocalo em uma collection???? ou existe outro geito de se fazer isso??? Valeu a todos Fernando PS: GOSTARIA DE COLOCAR A TODOS QUE ESSE EH O PRIMEIRA LISTA QUE EU PARTICIPO QUE AS PESSOAS SE AJUDAM DE VERDADE... PARAB�NS A TODOS -----Mensagem original----- De: Michael Santos [mailto:mister__m@;hotmail.com] Enviada: s�b 02/11/2002 01:09 Para: [EMAIL PROTECTED] Cc: Assunto: Re: [enterprise-list] classes DAO/Value Object ----- Original Message ----- From: "Fernando Rubbo" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: [enterprise-list] classes DAO/Value Object > Ola a todos... > Pessoal... aqui na empresa onde eu trabalho.. estamos migrando > um sistema inteiro para J2EE, o problema eh que ninguem conhece > a tecnologia direito.. minha duvida eh a seguinte.. > Inicialmente nos iriamos fazer todo o acesso a banco com Entity... > depois vimos que ficava muito lento e tinha muitas restri��es... Como vcs viram q ficava mto lento? Fizeram benchmark??? Poderia explicar como chegaram a estas conclusoes??? > dai decidimos usar o DAO, mas o pessoal quer retornar do DAO > um ResultSet em vez de VO.. Isso pode vir a dar problemas > futuros??? quais??? Fazendo isto vc vai estar amarrando camadas diferentes da aplicacao entre si, perderah type-safety e terah problemas de base de dados explodindo na camada de apresentacao, com dificuldade de manutencao e debugging. -- Michael Nascimento Santos Sun Certified Programmer for the Java 2 Platform Sun Certified Programmer for the Java 2 Platform 1.4 Moderador SouJava - www.soujava.org.br --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED] ---------------------------------------------------------------------------- ---- --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED] --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED] ---------------------------------------------------------------------------- ---- --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED] --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
