| Autor |
Mensagem |
|
|
Estou com o Guilherme , sinceramente ? prefiro ficar com os padroes de mercados, a especificação, e não os padroes "pessoais"
Afinal , o proprio JBoss que sugeriu a mudanca no EJB 3.0 nunca implementou 100% das funcionalidades da especificação e fica dando pitaco...
Aos defensores do JBoss , usem uma vez soh o Oracle AS , ae depois conversamos...
|
 |
|
|
kuchma wrote:
chun wrote:e na melhor das hipoteses... que vc consiga... vai ser "a sua versao do hibernate" contra a oficial... que beleza humm ?
Nao posso participar da discussao porque efetivamente nunca usei EJB - mas o Hibernate eh software livre e voce pode enviar as correcoes ao projeto que, com certeza, elas serao incorporadas na proxima versao.
Marcio Kuchma
Quem assina embaixo ? me desculpe mas estou falando de um projeto onde vao ser gastos alguns milhoes de reais... quero saber quem assina em baixo sobre essa sua afirmacao...
|
|
|
|
Sinceramente ,
o Gilherme chegou onde eu estou tentando dizer...
esse negocio de "hibernate deu pau senta e arruma" eh tao lenda quando o "EJB deu pau , processa a empresa" , quero ver vc da noite pro dia debugando o hibernate e arrumando ele... eheheh
e na melhor das hipoteses... que vc consiga... vai ser "a sua versao do hibernate" contra a oficial... que beleza humm ?
Sinceramente , continuo seguindo os padroes... prefiro apostar em EJB+ Container que HIBERNATE...
mais uma vez tem vente coparando EJB 1.0 para 2.0 , meu amigo , soh lamento... quando a versao eh muito nova , é normal terem estes pulos , o proprio java teve disso da 1.1 pra 1.2 , prq sera q chama Java2 neh ? e o AWT ? vai me dizer q java eh uma merda prq vc teve que refazer em swing... essa portabilidade ae que vc reclama ninguem esta imune... nem o hibernate , se vc usar a especificacao 3.0 por ex: os containers vao ser obrigados a suportar a 2.x , vc mesmo especifica no xml qual a versao da especificacao que esta usando... entao... o dia q der na telha eh soh usar a 3.0 ... mas o que importa eh que estou dentro de padroes... e que se eu falar com alguem ... sobre meu projeto ele vai saber do que estou falando...
Repito , continuo usando e nao tenho tido mais problemas  , apenas tenho tido que LER MUITO... pois pra quem veio de DELPHI+MYSQL , EJB eh coisa de outro mundo.
|
|
|
|
pcalcado wrote:Chun,
Não esqueça de atualizar este tópico em algun meses. Queremos muito saber se você aidna acredita na especificação EJB...
[]s
Yeap , por enquanto estamos desenvolvendo e CLARO com algumas dificuldades , mas esta valendo a pena , o xdoclet ajuda muito... a coisa toda fica bem portavel...
|
|
|
|
Guilherme Silveira wrote:metodologia de desenvolvimento com ejb:
1. pergunte ao coordenador/gerente se voce precisa de objetos distribuidos. se nao precisa va para 10. se precisa, va para 2.
2. pergunte ao coordenador/gerente se a data de previsao de entrega do projeto eh menor que 3 meses, se eh, va para 10. se for maior de 3 meses va para 3.
3. pergunte ao mesmo se o seu projeto tolera atrasos. se nao, va para 5, se sim, va para 4
4. voce PODE escolher EJB. FIM
5. voce nao pode atrasar? o projeto ja nasceu morto entao.... FIM
10. voce nao precisa de objetos distribuidos? tem tempo curto para aprender e fazer algo bonito? para que perder tempo a toa?
ejb (entity e session) nao faz muito sentido se voce nao precisa escalabilidade na horizontal....
HAHAHA... adorei esse esquema... perfeito 
Vou ateh guardar pra quando me perguntarem...
|
|
|
|
monster wrote:chun nos ja sabemos implementar ejb , o q estamos precisando de saber sao as metodologias utilizadas pelos desenvolvedores de ejb para saber o q eles priorizam na modelagem e codificacao de ejbs para q a interface da aplicacao seja a mais completa possivel
lucas
vixe , sua primeira mensagem nao dava essa nocao... mas acredito que o padrao quem faz eh a especificacao e nao "os outros" , J2EE tem uma especificacao forte... e modelagem de dados estao dentro dela... tem um livro ( apezar de voce nao me ouvir ) que retrata estes padroes no desenvolvimento: "Padroes de Projetos em J2EE (da editora BookMan)"
Lah tem tudo isso que vc quer saber...
Não adianta nada voce fazer tudo "ao se jeito" , no final vai ter gargalos de performance e vai culpar a plataforma.
Ler eh o melhor remedio nestas horas... tudo que vc "acha que sabe" vai pro lixo na maioria das vezes...
|
|
|
|
pcalcado wrote:Use Data Transfer Objects e Business Delegates.
sakei... vo's tmb ajudao...
VALEU !
|
|
|
|
Estou com duvidas na passagem do em entity... pelo que eu sei Entity Beans não são feitos para ser operados diretamente pelos clientes e sim por session beans...
Suponha o seguinte:
Tenho um entity CMP Pessoa , e um Session que acesssa ele chamado PessoaSession , do meu cliente eu quero manipular uma "pessoa" e repassar ao meu session para ele repassar para o bean
<PESSOA> -> PESSOASESSION -> ENTITY...
como se da essa passagem / ligacao... na manipulacao dos dados ? por exemplo eu pesso pro PessoaSession um entity pessoa e ele me retorna o q ? essa passagem nao esta bem clara para mim...
|
|
|
|
monster wrote:Olá a todos, estou fazendo um levantamento com todos que trabalham com ejb em alguma empresa ou como freelancer para saber, como é seu modo de trabalho(metodologia no desenvolvimento) pois onde eu trabalho vamos desenvolver uma aplicação para agilizar extremamente o desenvolvimento de aplicações distribuídas utilizando ejb.
Estou atuando em uma empresa que esta visando migrar suas aplicações de delphi + bd para EJB + CLIENT SWING
E te confesso uma coisa... Java pra client eh uma M... , nao prq ele nao funciona, e sim prq quase tudo vc vai ter q fazer na mao... o que programavamos em delphi vamos ter q programar na mao novamente , estamos tendo alguns probleminhas para migrar editor de textos com RTF+JUSTIFICACAO , mas esta valendo a pena
Já EJB estamos estudando muito , o troco realmente promete fazer mizéria , e faz mesmo , porem voce tem que ter uma nocao MUITO boa da pltaforma ejb , eu recomento vc ler 3 livros soh pra comecar...
"Java em 21 dias editora CAMPUS"
"Dominando Enterprise Java Beans de Ed Roman , editora BookMan"
"Padroes de Projetos J2EE tambvem da BookMan"
Apos a leitura destes 3 livros ( que podem ser adquiridos na submarino ) voce vai estar apto a dar palpites , nao adianta , nao fique se masturbando que sem a teoria voce simplemente nao vai ter nocao do TAMANHO da plataforma J2EE
monster wrote:
Caso você trabalhe com isso e queira deixar sua contribuição agradecerei bastante. Lembrando essa enquete esta sendo feita para que a aplicação agrade a gregos e troianos.
Minha contribuicao eh , se vc esta disposto a aprender MUITA coisa , e ter bastante servico ( pois vc quebra uma serie de paradigmas antigos ) , use EJB , mas veja se realmente EJB serve pra vc... prq se sua aplicacao for meramente uma "interface para um banco de dados" , EJB soh vai complicar as coisas ... e estes livros vao te dar a nocao juficiente para isso.
Detalhe , se vc quer ter uma pequena nocao de como vc nao consegue agradar a gregos e troianos , veja esse topico aqui mesmo do GUJ :
http://www.guj.com.br/posts/list/17977.java
Uma pequena discussao sobre EJB abordando apenas um pedacinho só da especificação J2EE , e veja como é "IMPOSSIVEL AGRADAR A TODOS"
|
|
|
|
jrodrigues wrote:Só acho que você é um EJB Evangelist e acha que EJB vai resolver todos os seus problemas.
Sou mesmo , se vc nao gosta da plataforma que vc opera... paciencia mas eu acho ela muito solida e competitiva, quanto a todos os problemas , muito pelo contrario , acho que para a minha situacao ela se encaixa como uma luva... Nao estou falando de um sistememinha besta de 30 milhoes de registros... estamos falando de algo bem maior...
jrodrigues wrote:
Só disse que tem contexto certo para utilizá-lo.
Já viu a implementação da aplicação Pet Store com EJB? Quase 3000 LOC!
Já viu a implementação com hibernate? 970 LOC!
Muito bla bla bla e pouca pratica , aqui eh soh ouco falar em bla bla bla , ninguem que realmente fez algo descente pra dar uma opiniao... apenas baseados em "opinioes alheias" , paciencia... depois outro vez me dizer de teoria... Mas farei teste com esses "LOCKS" , acho que eh muito exagero... tah parecendo a MS quando falou que o PetSotre era 10x mais rapido em .net que em java.
jrodrigues wrote:Anyway, acho que vou gastar o teclado para argumentar com você porque não vai adiantar mesmo.
Adianta sim , soh que nao sou fã do hibernate , quem eh enagelizador dele eh voce... leia seus proprios posts... e o pior... eh evangelizador e nao admite... , mas nao gosto dele , acho q ele foje do atual padrao e ponto final , e tem outra... pensei aqui... vou ter que codificar XML de qualquer jeito... entao nao vejo vantagens... vou desenvolver algo HJ e nao na versao 3.0 , na 3.0 apenas vou migrar... nao posso viver no "se... se... se..." ,
O dia.... que a 3.0 ficar implementada descentemente , ou melhor... o dia que ela realmente sair de verdade talvez eu reveja algo...mas se seguir o padrao da passsagem pelas versoes vou rodar em um container 3.0 tranquilamente , dae quem sabe nesse dia eu mude , porem... nao vou seguir algo incerto (JCP eh um processo democratico , tudo pode acontecer ) simplesmente pq todos estao usando...
jrodrigues wrote:Hibernate é um padrão.
Eh... um padrao na sua cabeca... leia a especificacao do EJB 2.1 e veja se diz HIBERNATE lah... se disser blz... 3.0 eh outra estoria... o proprio JBOSS ( que por uma infelicidade enorme sugeriou o hibernate pra 3.0 ) tah cheio de preview... versao definitiva... 'sabe deus'
jrodrigues wrote: Se você diz que isso não funciona em todos os containeres ... não sei o que te dizer. Funcionou em todos os que usei até hoje e não foram poucos.
Eu disse que enquanto nao virar padrao... na especificacao ATUAL , pouco me importa se roda em N containers... nao eh padrao na plataforma J2EE ainda e ponto final. Nao vou engolir padroes impostos por "pessoas" , senao jah estava usando Prevayler , afinal... todo mundo diz que eh um padrao e roda em tudo... bullshit.
jrodrigues wrote:
Afinal, java puro tem que rodar em qualquer container, né?
hahaha, vc ainda tah nessa de W.O.R.E. , ok ok , vai lah... padroes de especificacoes existem exatamente para impedir gente como voce de "reinventar a roda, soh que quadrada" com ideias proprias e se levar em consideracao um contexto como todo, realmente a amazon.com deve estar errada , afinal... eles devem ter soh umas 2 milhoes de transacoes por minuto mesmo neh ? soh sao pioneras nesse ramo de livros na internet , prq sera q eles NAO USAO O PADRAO DE MERCADO HIBERNATE ? bom... ae o envangelizador do hibernate deve ter algo a dizer...
Bom , eu jah tinha encerrado a discussao no post anterior , mas se vc quer continuar a bater boca com os "padroes da sua cabeca" e os "achismos" tudo bem... continue... eh isso mesmo que preciso... saber TODOS OS PONTOS NEGATIVOS... vc ainda nao entendeu que eh PROFISSIONAL , tudo bem... eu finjo que eh pessoal soh pra vc ter o que escrever...
|
|
|
|
Well , valeu a discussao , muito obrigado pelas opinioes de voces , e levarei tudo em conta na minha escolha... que ainda eh incerta.
E desculpa caso tenha ofendido alguem , mas preciso esmiucar o maximo e em detalhes esse "repudio todo" em cima dos Entitys...
Muito Obrigado mesmo
|
|
|
|
jrodrigues wrote:
Single-Vendor-Lock-In onde? Me mostra... 
Continuou sem responder a pergunta.
Hibernate é Java puro, e portanto roda em qualquer container.
Nao esta dentro da especificacao , nao tem obrigacao de ser suportado , nao tenho de ficar "enjambrando" em outro container... ou na mao do cara que esta "Implementando o hibernate" , prefico ficar na mao da JCP..
jrodrigues wrote:
Hibernate é uma biblioteca, um framework, entende? Pra funcionar out-of-the-box em qualquer container J2EE.
Nao quero auto-of-box... se eu quisesse isso , ficava programando em delphi usando DCOM+ , quero algo solido e que esteja dentro de padroes
jrodrigues wrote:
"Implementar a spec ou não" não te garante portabilidade. Veja o caso dos entity beans. CMP 1.1 não funciona. CMP 2.0 não é compatível com CMP 1.1 e a CMP 2.1 introduziu funcionalidades não compatíveis com versões anteriores.
Bem primeiro que versao 1.1 nao eh discutivel , pois a versao 1.0 do proprio java era uma uma piada ( ou vc adora o awt ?)... estamos falando de algo maduro... da 2.0 , as alteracoes q foram "introduzidas" vc arrumava em uma tarde de trabalho... e nao na codificacao da persistencia TODA da sua aplicacao... detalhe... somente em alguns casos... da maneira que vc fala parece que EJB 2.1 simplemente mudou toda maneira de trabalhar da 2.0 , e isso nao eh verdade e vc sabe disso.
jrodrigues wrote:
Além do mais, CMP's são obrigados a usar deployment-descriptors proprietários... O que você me diz disso?
olha , o unica coisa que precisei fazer "proprietaria" eh dizer como ele "persistir os objetos" se eh em um pool , e o nome dele... mais nada... 15 linhas de XML por servidor , xdoclet faz isso pra mim... relax esse negocio de dizer que Entity eh trabalhoso soh se vc usar notepad mesmo... prq o xdoclet faz todo o trabalho sujo
|
|
|
|
jrodrigues wrote:
Single-Vendor-Lock-In onde? Me mostra...
Hibernate é um padrão de indústria assim como é EJB, ou OJB, ou até JDO.
Sem falar dos Cayenne da vida.
Simples.... Hibernate esta na especificacao J2EE ? se nao estiver... nada garante que um container que implemente JE22 venha suportar isso...
logo , fico na mao do meu vendor...
jrodrigues wrote:
Cara, você quer distribuição? Então use SessionBeans, BusinessDelegate e ponha o Hibernate ORM na veia. Não esqueça do Spring.
Ueh... mas pelo jeito estao confundindo as coisas... prq ateh... EJB como um todo era ruim... agora vamos usar SessionBeans... leia os comentarios anteriores... onde dizem que EJB LOUCURA... e SessionBeans estao dentro da especificacao e do que se entende por EJB.
jrodrigues wrote:
Mas persistência com Entity Beans ... CMP's, aí vc tem o Vendor-Lock-In utilizando features proprietárias dos vendors.
Errado, uso TUDO dentro de uma especificacao aberta que eh regida pela JCP , se vc nao acredita nisso , entao nao sei prq vc usa java... nao tem nada de LOCK-IN nisso , a especificacao eh aberta e eh absorvida pelo mercado, e Entity beans CMP nao sao "features proprietarias" eh uma especificacao , como ela eh implementada , pouco me importa , se for da maneira porca... pulo pra outro EJB Contaiener e pronto.
jrodrigues wrote:
Digo ainda mais, crie uma camada de abstração com AbstractDAOFactory da vida e escolha o modo de persistência como bem entender.
Soh falta vc me dizer que ae estou "facilitando mais as coisas" , um controle do controle ? nah... pra isso q existe Entity Beans para vc ABSTRAIR a persistencia... e nao "inventar moda".
|
|
|
|
smota wrote:
POJO = Plain Old Java Object, ou seja, nenhuma implementação de interface ou herança requerida - faça como quiser.
Nao precisa de um EJB Container, ele roda simplemente em um servlet container qualquer (inclusive no do seu AS preferido) .....
Puts , mas ae eh reinventar a roda... pra q fazer assim se jah tem algo pronto ?
smota wrote:
O Coherence é que faz a distribuicao (cache e cluster) ... detalhes eu desconheco.
Ou seja... no final vc tem o mesmo cenario de um container EJB... eh a mesma coisa soh que diferente...
smota wrote:
Nonon ... um cara que manje de clipper, desenvolve a mesma aplicacao (distribuida, com seguranca, etc. etc.) no mesmo tempo que um cara que manje Java? Acho que nao (na verdade nao sei, nunca vi clipper na minha vida) ....
Segundo sua afirmacao anterior... SIM , afinal "ele aprende"
smota wrote:
Pra nao ficarmos dando voltinhas .... continue trabalhando com EJB pq afinal de contas a teoria do spec é legal é valida (de verdade) ... e faça um projetinho de brincadeira tentando usar todos os serviços que vc tem com EJB usando frameworks alternativos .... e tire suas conclusoes ....
Exatamente , estou fazendo testes e etou tirando minha conclusao deles... e por enquanto Entity Beans CMP nao sao o jeito mais facil , mas sao o jeito mais seguro de garantir um futuro e de capacitar minha equipe dentro de padroes validos e testados.... o que nao quer dizer que eu nao possa usar HIBERNATE , afinal em UM pedacionho do codigo pode ser que eu precise... mas o resto das minhas 99% da aplicacao eu rodo dentro de um padrao... e esses 1% eu deixo pra pensar mais tarde como resolver...
|
|
|
|
jrodrigues wrote:
Falou tudo.
No final, o engine ORM utilizado vai ser Hibernate mesmo. 
Bem, de todo o jeito, nowadays, EJB não deve ser a primeira escolha para se desenvolver persistência.
Deve ser a última.
Mas ae estamos tendo uma discrepancia ... prq imagine o cara que jah vem seguindo as especificacoes... no final... o que ele teve q mudar na ida pra EJB 3.0 ? NADA , imagine q eu escolhesse "hibernate" e simplesmente ele fosse "mais um" , o que aconteceria comigo no final ? Single-Vendor-Lock-In , e isso usando a plataforma java eh inadmicivel no meu ponto de vista...
Quanto a primeira escolha... nao esta sendo Entity Beans para mim , esta sendo a ultima opcao... prq eu poderia muito bem jogar o codigo direto em meus Sessions e sair por ae... problema eh enfrentar o futuro e a manutencao disso...
|
|
|
|
|
|