morte EJB???

calmaaaaaa pessoal. cada um defenda seu topico, nao tem problema ALGUM em falar que um acha uma coisa uma droga, outro acha muito bom.

eu nao conheco EJB. nao posso falar anda. Mas ja fiz projetos bem rapidos, e nunca senti a necessidade. Mas poderei vir a sentir.

Alguns comentarios importantes:

ozielneto wrote:
Estude mais sobre os EJBs, e verá que eles não foram mal planejados assim, é que as pessoas usam eles de forma errada.

O Oziel esta coberto de razao nesse ponto nao? Mas vamos lebrar que as pessoas usam de forma errada por causa do "hype" que existe em torno do ejb.

O Claudio tambem fala algo interessante aqui:

claudio wrote:
Agora se nao usar j2ee, vc vai usar o que?

Voce fala mais exatamente de EJB neh? Porque servlets rules e ninguem fala o cotnrario.

claudio wrote:
1)fazer na mao

Esta ai uma ideia interessante, se for uma empresa e tiver um produto e metodologia. Caso contrario, suicidio.

claudio wrote:
2)usar um framework de uns nerdzinhos por ai

Poxa. Tem o Hibernate e OJB que fazm persistencia de banco de dados e tem uma LEGIAO de fas. Struts e WebWork nem se fala. E tem mais dois, que nao sei se todo mundo conhece: O AltRMI (versao apacheana do RMI) e o Entreprise Object Broker, baseado no OJB e AltRMI, para confrontar DIRETO o EJB. Apache tambem. Eu amo os nerdzinhos do apache/jakarta!

claudio wrote:
3)apostar em um framework de peso, encabecado por gente grande.

Jakarta!

Senti que todos acham que, se uma empresa utiliza EJB apra os projetos mais simples, vai acabar se queimando nao? Mas que em um projeto grande, que precisa ser muito bem componentizado, e especialmente distribuido, eh muito interessante, apesar de eu nao saber do que estou falando

.

Outra coisa, quando falei no topcio sobre java3, que queria morte ao EJB, foi CLARAMENTE uma brincadeira.

Mais uma vez, eu *concordo* que para sistemas distribuidos, escalabilidade, load-balance, controle de sessao, controle de crash etc etc EJB pode ser uma otima saida, pois sao coisas complexas de realizar "no braco".

Para tudo ha uma solucao, mas fica claro que a maior parte quer EJB para tudo ou para nada. O ponto que eu mais nao concordo eh sair dizendo que EJB eh A solucao para algum problema. Ele poder ser para DETERMINADO problema, e esse problema geralmente sao os maiores, onde os fatores do primeiro paragrafo se aplicam.

Assim como o Paulo comentou, desejar a morte ao EJB eh brincaderia, modo de expressao. Eu ficaria super feliz se EJB perdesse as dezenas de problemas atuais, pois assim o Java ficaria ainda mais forte do que ja eh. Afinal, todos queremos Java.
Porem, mais uma vez, eu sou do time que defende a melhor solucao, seja ela qual for. Se provarem que EJB de fato eh melhor para o meu problema, otimo, usarei ele pois caso contrario eu estaria perdendo, mas se nao for, nao vou usar por simplesmente ser EJB.

Documentos e documentos pela net falam muito mal de EJB, outros milhares falem muito bem, cada um tem seu ponto de vista. Mas a maior parte nao sustenta o ponto de vista, querem 1) ou enviar goela abaixo; 2) ou chutar tudo.
Assim como comparacoes de Java x .NET somente levam em consideracoes ".NET tem isso, Java nao tem aquilo" ( e vice-versa ), a discussao em torno de EJB eh "EJB te permite escalar de maneira muito simples, permite recover de sessao se der crash, permite isso e aquilo..", porem parece que o pessoal esquece de analisar um fator MUITO importante: "Preciso disso para o meu sistema? ganhar 1 mes no prazo por usar EJB vai compensar realmente?"

Eu defendo a melhor solucao, e nao me importaria de usar EJB de visse que ele poderia me ajudar.

Pagando bem, programo ate em .NET.

Rafael

Rafael Steil wrote:
Pagando bem, programo ate em .NET.

ahhhh. pera la. xingar tudo bem. mas agora isso? morte ao rafael!!!
uhauhauhauh

Paulo Silveira wrote:Poxa. Tem o Hibernate e OJB que fazm persistencia de banco de dados e tem uma LEGIAO de fas. Struts e WebWork nem se fala. E tem mais dois, que nao sei se todo mundo conhece: O AltRMI (versao apacheana do RMI) e o Entreprise Object Broker, baseado no OJB e AltRMI, para confrontar DIRETO o EJB. Apache tambem. Eu amo os nerdzinhos do apache/jakarta!

Pois é, tá cheio de projetos tentando "reinventar melhor" a roda dos EJBs. O Hibernate, por exemplo, resolve muito bem a questão da persistência, aliás, e eu sou fã de carteirinha dele pra usar naqueles casos onde vai ter mais leitura do que escrita no DB. É rápido, e o desenvolvimento, aliado ao XDoclet, WebWork e Velocity, fica uma baba total. Sai mais rápido que muita gente programando em PHP por aí, até.

Agora, que empresa te deixaria começar um projeto usando essas ferramentas? O difícil, em muitos casos, é "vender" alternativas mais simples aos EJBs e JSPs. Tenho experimentado bastante isso tentando vender o peixe do WebWork em empresas que estão pensando em usar o Struts. Impressionante a trabalheira que dá convencer os caras, e olha que o Struts também é free, e também é considerado "alternativo"!

No fim das contas, o pessoal acaba usando a J2EE "bare metal" pq tem medo de bibliotecas e frameworks opensource...tsc tsc...

Pagando bem, programo ate em .NET. (Rafael Steil)

há algumas coisas que o dinheiro não compra, pro resto tem mastercard, não?

mas, falando sério... acompanhei meio de longe este tópico, mas, resumidamente (ou nem tanto), minha opinião sobre o mundo do EJB é esta:
1. a spec. é muito boa (há problema, claro, nada é perfeito, mas como disseram, os problemas vão se resolvendo à medida que vamos usando a tecnologia), resolve quase todos os problemas que as soluções corporativas normalmente têm (fail over, controle de concorrência, etc etc...); mas vale ressaltar: soluções corporativas; no "site do zé", usar EJB é um exagero (podem dizer que o tal "site do zé" pode, do dia para a noite, virar uma sensação da internet e precisar escalar rapidamente; se isso ocorrer, então o erro não foi não ter usado EJB no início, mas foi não prever - ou seja, erro de análise pré-projeto - a possibilidade do "site do zé" de virar este imenso sucesso);
2. há muita gente que fica excitado em experimentar tecnologia; isso não é errado, muito pelo contrário; porém, uma coisa é experimentar, testar, aprender esta nova tecnologia, outra é aplicar isso num projeto real sem analisar aquela velha dupla "custo-benefício" e sair de cara considerando EJB como A SAÍDA. E, por mais que digam que não, isso é muito freqüente.
3. há os movidos pelo modismo do EJB, que acham que EJB é tudo. Para estes, vale lembrar que calça boca-de-sino não é mais moda desde a década de 70

.

Em suma, acho que "morte aos EJBs" (como eu já defendi) é um radicalismo. O ideal seria "morte ao modismo do EJB".

e isso é tudo, p-pessoal...

abrindo um parênteses:

No fim das contas, o pessoal acaba usando a J2EE "bare metal" pq tem medo de bibliotecas e frameworks opensource...tsc tsc... (Carlos Villela)

acho que algumas coisas como Velocity e o Webwork sào uns exageros. JSP+JSTL (ou, o JSP 2) geralmente dão conta do recado

Não me referi a ninguem falando do morte ao EJB especificamente, na realidade esse é o título do tópico.

Acho legal que se chegue a um entendimento que o mau uso de uma tecnologia, não faz dela uma tecnologia ruim, o ruim é quem não sabe usar.

Não existe tecnologia que seja a única alternativa para determinado problema, sempre tem uma outra maneira de se fazer as coisas.

Acho muito válido questionar sobre a qualidade disso ou da quilo, a utilidade etc. Não devemos ir aceitando tudo por modismo ou qualquer outro motivo. E o questionamento ajuda a resolver problemas e criar novas soluções e alternativas.

Também acho válido em muitas vezes "reiventar a roda" sim, pois se vc achar que determinadas soluções não são as melhores e vc pode fazer melhor, todos podem ganhar com isso. De outra maneira não teriamos projetos concorrentes na Jakarta por exemplo.

Quanto a Jakarta, cara eu adoro os projetos da Jakarta o pessoal é 10, e se a alternativa deles ao EJB for melhor, serei mais um a usar.

E Daniel Quirino, quanto ao receio de algumas empresas estarem usando projetos OpenSource, isso vem diminuindo, pois empresas como IBM, SUN, BORLAND entre outras estão apoiando e usando iniciativas OpenSource.
O que as empresas estão procurando hoje em dia é usar "padrão de mercado", muitos dos projetos OpenSource de sucesso, são praticamente padrões de mercado ou estão se tornando. Por isso muitas vezes existe um receio de trocar um framework por outro.

quanto ao receio de algumas empresas estarem usando projetos OpenSource, isso vem diminuindo, pois empresas como IBM, SUN, BORLAND entre outras estão apoiando e usando iniciativas OpenSource. (Richardson)

Aham. JSF é praticamente uma fusão de JSTL + Struts.
Eu não tenho receio algum de usar qualquer framework OS nos meus projetos, desde que eles sejam perfeitos no quesito "faça tudo o que eu quero fazer de maneira mais fácil e produtiva". Tanto é que alguns deles eu acho imprescindível, como Hibernate/TJDO, AspectJ (estou vendo o Aspectwerks, que o Carlos tanto adora), log4j. O que eu quis dizer com

acho que algumas coisas como Velocity e o Webwork sào uns exageros. JSP+JSTL (ou, o JSP 2) geralmente dão conta do recado

é que nem sempre vc precisa recorrer a frameworks para se ganhar em produtividade. Claro, este lance de produtividade tem muito a ver com a familiaridade do programador com determinada ferramenta, mas não creio que seja preciso aprender uma nova ferramenta/framework/o que for pois há muitas coisas no "bare j2ee" podem ser uma grande mão-na-roda.

Richardson wrote:
Também acho válido em muitas vezes "reiventar a roda" sim, pois se vc achar que determinadas soluções não são as melhores e vc pode fazer melhor, todos podem ganhar com isso. De outra maneira não teriamos projetos concorrentes na Jakarta por exemplo.

Voce disse TUDO aqui. Serio mesmo.
Eu tenho essa mesma ideia. Soh que muita gente mostra que a Microsoft sobrevive fazendo exatamente o cotnrario. Nunca tem 2 apis pra mesma coisa, nunca....

Paulo Silveira wrote:Soh que muita gente mostra que a Micro$oft sobrevive fazendo exatamente o cotnrario. Nunca tem 2 apis pra mesma coisa, nunca....

Pois é...será que dá pra contar nos dedos quantas APIs tem pra fazer uma toolbar? Ou quantas APIs diferentes dá pra usar pra desenhar dentro de uma janela?

Notícias, artigos e o maior fórum brasileiro sobre Java