Facelets + JSF > Struts. Definitivamente.
JSF > Struts? Eu acho. Mas, your mileage may vary… 
Respondendo ao Rubem:
- Ae que está a questão… hibernate botou um plus na SPEC… e eu vou trabalhar com a SPEC e nao com o hibernate… entao não me beneficio desta “feature” logo… se estou dentro da SPEC não preciso nem saber o que é hibernate… e vc pode falar que não… em 1% dos casos você até pole puxar o HibernateSession diretamente do EntityManager para fazer algo que “só ele faz” , mas isso é 1% do seu software… e uma equipe tem os outros 99% para se preocupar…
2)10 Vezes ? Acho que voce REALMENTE precisa fazer novos testes… use apenas o WebContainer do Glassfish ( que nem voce usa o tomcat ) e vai ver algo BEEEEEEMM diferente que 10 vezes… um numero BEEEM menor… com um plus de algumas toneladas de servicos que podem ser utilizados e sem nenhum “guru da programacao” reinventando a roda.
3)Que culpa eu tenho se voce vem com essa de 10x mais lento sem testar ? Se é para falar besteira… quero falar tmb 
Leozin,
Não estou defendendo nem o glassfish e nem o NetBeans, apenas respondendo ao rubem que simplesmente acha EJB3 a coisa mais dificil e inutil do universo… só que provavelmente ele parou no EJB 2 e agora prega isso ae…
Disseminar informacao incompleta não dá…
Bom, Chun posso dar minhas considerações ?
- O Spring é muito mais que um container para IoC e sabes disso, mas me pautando somente nessa feature, EJB não faz IoC de Pojos. Isso já é motivo suficiente para algumas arquiteturas fazerem uso do IoC do Spring, como o Grails, que faz uso dessa característica para injetar recursos sem serem EJB.
Vou dar uma rápida passadinha no Spring, somente para lembrar algumas coisas :
- Framework MVC - ActionBased, pois em muitos cenários de negócio ainda pela especificação JSF 1.0 , ponto até que o Gavin King quer que mude é o clico de vida statless - Alternative stateless UI component lifecycle - http://in.relation.to/Bloggers/GavinsBlog/Tag/EE6+Wishlist.
Só esse monto para usários simultâneos, dependendo do perfil da aplicação já faz a solução Component Based não ser viável por questões de ROI, já que MVC custaria infinitamente mais barato.
Lembrando que o cliclo de desenvolvimento MVC do Spring já é coberto por annotations.
- Spring AOP, para retirada de todo interesse ortogonal, uma das novas funcionalidades do Weblogic 10 foi a inclusão de AOP para instrumentação de excessões, só para citar um exemplo de utilização.
Cara, poderia falar de OSGI, outros projetos Spring como Batch, WebServices, Integration mas acho que já sacou o que eu queria passar, o EJB3 não vai descartar o uso do mesmo, à não ser pelas pessoas que só faziam uso mínimo da funcionalidade de IoC.
2- JPA e Hibernate - Bom , quem nasceu primeiro ? Nesse caso simples, hibernate, então ele não foge à especificação e sim a especificação que não implementa recursos interessantíssimos como Criteria, Projections, Statistics e por aí vai. Vai demorar muito à eu usar “JPA” como vem de caixa e falando em provider, qual é o seu provider JPA ? Hibernate ? Se for, porque não fazer uso intensamente ? Compliance ? Sinceramente as especificações até só deixando a desejar. Quem apostou em especificação Entitys BMP está com um grande problema, sem falar de outras tantas, como Portlets 168 e por aí vai …
3 - Acegi ? - Amigo acho que você não tem a mínima noção do que acabou de dizer. ACEGI é um Sr. Framework, tirando que ele implementa a JSR 250 , dos EJBs , o mecanismo de votação (http://www.acegisecurity.org/guide/springsecurity.html#authorization) para provisionamento de permissões é fantástico. Acho que vale à pena ler a ocumentação e entender que ele não é somente um autenticadorzinho de plantão - http://www.acegisecurity.org/guide/springsecurity.html leia e depois comente algo.
4- Struts - Realmente esse pode morrer !! Ninguém vai sentir falta 8)
Sem duvidas Kenobi !
-
Minha questão não é o que o Spring faz ou não faz… a questão é querer usar Spring para fazer o que EJB faz… e é nisso que estou comentando… mais um framework para fazer a mesma coisa ? Então usa o que já esta disponivel pelo container… Agora se você quer recursos exclusivos… otimo… são outros 500… agora… enfiar mais um framework dentro da aplicação apenas para “fazer de outra forma a mesma coisa” eh que não acho vantagem…
-
Mais uma vez… o meu foco na discussao não é o que o hibernate faz ou não faz… a questão levantada foi “padronizar o desenvolvimento para que a curva de aprendizagem fosse menor” e nisso JPA ganha… todos da equipe trabalham sempre da mesma forma… e em 1%-10% dos casos fogem a regra
Quem veio antes ou não não vem ao caso, pelo menos não no ambito do inicio da discussao… -
é um sr. framework, mas será que todas aplicações precisam realmente desse sr. framework… MAIS UMA VEZ… não venho aqui comentar se ele cozinha e faz café… e sim dentro de um desenvolvimento se o mesmo é realmente imprecindivel em todos projetos que fazem uso de autenticação enterprise… mais um framework… mais um aprendizado…
Kenobi… não estou aqui discutindo qual framework faz mais… apenas comentando que algo “all in one” em 80% dos casos é uma coisa boa… fazer sempre da mesma forma e de uma maneira em que o cara não precise se matar em 505 maneiras diferentes de fazer algo igula (ou muito proximo)…
Frameworks estão ai e tem seu valor… mais algo que sinto falta no java ( que existe a decadas em .net) é que eu não tenha que sair contratando “mini-gurus” de frameworks… que pelo menos eu consiga exigir algo padrao… quero ver no mercado voce achar facil facil quem junte esses 4 framewoks de maneira tranquila e “transparente” no desenvolvimento, é uma tarefa bem interessante…
Não adianta discutir funcionalidade… já disse… o negocio é “por que EJB3?” então ae está a resposta
[quote=chun]Sem duvidas Kenobi !
-
Minha questão não é o que o Spring faz ou não faz… a questão é querer usar Spring para fazer o que EJB faz… e é nisso que estou comentando… mais um framework para fazer a mesma coisa ? Então usa o que já esta disponivel pelo container… Agora se você quer recursos exclusivos… otimo… são outros 500… agora… enfiar mais um framework dentro da aplicação apenas para “fazer de outra forma a mesma coisa” eh que não acho vantagem…
-
Mais uma vez… o meu foco na discussao não é o que o hibernate faz ou não faz… a questão levantada foi “padronizar o desenvolvimento para que a curva de aprendizagem fosse menor” e nisso JPA ganha… todos da equipe trabalham sempre da mesma forma… e em 1%-10% dos casos fogem a regra
Quem veio antes ou não não vem ao caso, pelo menos não no ambito do inicio da discussao… -
é um sr. framework, mas será que todas aplicações precisam realmente desse sr. framework… MAIS UMA VEZ… não venho aqui comentar se ele cozinha e faz café… e sim dentro de um desenvolvimento se o mesmo é realmente imprecindivel em todos projetos que fazem uso de autenticação enterprise… mais um framework… mais um aprendizado…
Kenobi… não estou aqui discutindo qual framework faz mais… apenas comentando que algo “all in one” em 80% dos casos é uma coisa boa… fazer sempre da mesma forma e de uma maneira em que o cara não precise se matar em 505 maneiras diferentes de fazer algo igula (ou muito proximo)…
Frameworks estão ai e tem seu valor… mais algo que sinto falta no java ( que existe a decadas em .net) é que eu não tenha que sair contratando “mini-gurus” de frameworks… que pelo menos eu consiga exigir algo padrao… quero ver no mercado voce achar facil facil quem junte esses 4 framewoks de maneira tranquila e “transparente” no desenvolvimento, é uma tarefa bem interessante…
Não adianta discutir funcionalidade… já disse… o negocio é “por que EJB3?” então ae está a resposta
[/quote]
Chun, acho que esta é uma visão estreita. Se você olhar para o cenário Enterprise HighEnd e não Mind-ranges, vai encontrar muito mais necessidades que imaginas. Quando começar a trabalhar com containers de processamento Mainframew como Tuxedo, precisar escalar soluções à 50k minuto entre outras, algumas coisas serão necessárias.
A arquitetura com Spring pode prover flexibilidade, para injetar um sistema de grid como GigaSpaces ou o Hibernate pode ser utilizado junto com o Coherence.
Particularmente preifro ter “opções” e alternativas ao mundo fechado .net. Aliás vai ver muita solução até mesmo de hardware, para contonar deficiências de desenvolvimento, como o parser de XML da IBM por exemplo.
Não estou excluindo o uso de EJB3, pelo contrário, gosto da tecnologia, entretanto os outros frameworks que estão aí também possuem o seu valor, isso que eu quis dizer e o mundo não gira exatamente igual em todas as companhias.
Neste exato momento estou num projeto SOA que possui uma arquitetura muito atípica e necessidades de integração distintas, mas isso é outro tópico.
Kenobi, continuando:
-
Certo… como você mesmo acabou de falar… “visão estreita” eu diria que é mais “pequenas/medias aplicações”… vejo muito nego por ae socando de frameworks tornando projetos simples em verdadeiras torres de babel… e é para estes casos que digo o que disse… e não para casos extremos.
-
Sim spring possibilita tudo isso… mas quem realmente que esta usando Spring que “sabe” OU pior… utiliza realmente isso ? Posso contar nos dedos… é que nem um povo a um tempo que criticava o MySQL por nao ter stored procedures e nem integridade referencial faziam em suas tabelas no Pg… meu ponto é “Use quando realmente for necessario” e não ficar enchendo de bagulhada para tornar o desenvolvimento na plataforma java um mundo de DOR… é para isso que tem um arquiteto… para dizer o que usar e não deixar isso simples e puramente na mão de quem programa…
As vezes a decisão deve visar um conjunto total e não apenas um. -
Eu ADORO ter opções (http://www.go-java.com/blog/2008/08/01/1217590877657.html) e este não é o caso , o caso é produção e renovação… e nisso ter milhares de frameworks é como ter milhares de componentes no velho delphi… um inferno para gerenciar a equipe…
-
Quanto a existirem outros framewoks que possuem o seu valor… eu já afirmei nas minhas outras mensagens… eu apenas tento matar uma girafa usando um rifle e não uma bazuca… deixo a bazuca para bombardear os EUA… hehe
-
Em seu projeto atipico , necessita de abordagens atipicas… então bora usar todo o potencial… voce acabou de chegar no ponto… ATIPICO… e os tipicos… voce teria a mesma abordagem ?
[quote=chun]Kenobi, continuando:
-
Certo… como você mesmo acabou de falar… “visão estreita” eu diria que é mais “pequenas/medias aplicações”… vejo muito nego por ae socando de frameworks tornando projetos simples em verdadeiras torres de babel… e é para estes casos que digo o que disse… e não para casos extremos.
-
Sim spring possibilita tudo isso… mas quem realmente que esta usando Spring que “sabe” OU pior… utiliza realmente isso ? Posso contar nos dedos… é que nem um povo a um tempo que criticava o MySQL por nao ter stored procedures e nem integridade referencial faziam em suas tabelas no Pg… meu ponto é “Use quando realmente for necessario” e não ficar enchendo de bagulhada para tornar o desenvolvimento na plataforma java um mundo de DOR… é para isso que tem um arquiteto… para dizer o que usar e não deixar isso simples e puramente na mão de quem programa…
As vezes a decisão deve visar um conjunto total e não apenas um. -
Eu ADORO ter opções (http://www.go-java.com/blog/2008/08/01/1217590877657.html) e este não é o caso , o caso é produção e renovação… e nisso ter milhares de frameworks é como ter milhares de componentes no velho delphi… um inferno para gerenciar a equipe…
-
Quanto a existirem outros framewoks que possuem o seu valor… eu já afirmei nas minhas outras mensagens… eu apenas tento matar uma girafa usando um rifle e não uma bazuca… deixo a bazuca para bombardear os EUA… hehe
-
Em seu projeto atipico , necessita de abordagens atipicas… então bora usar todo o potencial… voce acabou de chegar no ponto… ATIPICO… e os tipicos… voce teria a mesma abordagem ?
[/quote]
Bom na minha ótica você generalizou o uso do Spring. Não sei se está baseado em alguma pesquisa ou apenas vivência no cenário que atua. Particularmente enxergo muito mais no framework citado e se fosse utilizá-lo seria como citei. Talvez “as pessoas” como você mencinou o conhecem superficialmente, particularmente acho esse o mal de muitos que se dizem “Arquitetos” na nossa área. O cara conhece meia dúzia de tecnologias e fala que conhece arquitetura de software…complicado.
Quanto ao “comum”, pode se estabelecer um modelo como a proposta WebBeans - Seam, acho válida.
Olá
Este tópico virou uma discussão entre EJB3 e Spring.
Acho que o foco inicial era ver quantos ainda usam os EJB 2.x, que na minha opinião foram a maior tolice já inventada na área de TI. Ou ver quem já usa os EJB 3.x que quase não tem nada a ver com os EJB 2.x.
Acredito que ainda existam muitas aplicações usando a porcaria dos EJB 2.x. Sorte dos que podem trabalhar com EJB 3.x que são muito mais interessantes. Os que sofrem com EJB 2.x se consolam porque talvez possam ganhar mais ou trabalhar mais horas para obter o mesmo resultado.
O Spring, exceto o Spring-MVC, tem enorme valor. Quem teve a sapiência de usá-lo ao invés dos EJB 2.x, talvez hoje se arrependa porque perdeu a galinha dos ovos de ouro na manutenção ou redesenvolvimento dos sistemas feitos com eles.
Acho mesmo com EJB 3.x, o Spring ainda tem muita coisa boa e não acredito na história de quem usa Spring não usa JEE. O mesmo raciocínio para quem usa Hibernate ou JPA.
Porque a gente não volta a discutir EJB 2.x versus EJB 3.x?
[]s
Luca
[quote=Luca]Olá
Este tópico virou uma discussão entre EJB3 e Spring.
Acho que o foco inicial era ver quantos ainda usam os EJB 2.x, que na minha opinião foram a maior tolice já inventada na área de TI. Ou ver quem já usa os EJB 3.x que quase não tem nada a ver com os EJB 2.x.
Acredito que ainda existam muitas aplicações usando a porcaria dos EJB 2.x. Sorte dos que podem trabalhar com EJB 3.x que são muito mais interessantes. Os que sofrem com EJB 2.x se consolam porque talvez possam ganhar mais ou trabalhar mais horas para obter o mesmo resultado.
O Spring, exceto o Spring-MVC, tem enorme valor. Quem teve a sapiência de usá-lo ao invés dos EJB 2.x, talvez hoje se arrependa porque perdeu a galinha dos ovos de ouro na manutenção ou redesenvolvimento dos sistemas feitos com eles.
Acho mesmo com EJB 3.x, o Spring ainda tem muita coisa boa e não acredito na história de quem usa Spring não usa JEE. O mesmo raciocínio para quem usa Hibernate ou JPA.
Porque a gente não volta a discutir EJB 2.x versus EJB 3.x?
[]s
Luca[/quote]
Legal, particularmente já coloquei meu ponto de vista sobre o EJB, começo da idéia e alternativas à época com o Corba. Ele teve falhas como os Entitys e são bastante condenados por isso. Mas se olhar SessionBeans, MDB´s, JTA - Controle transacional, são pontos à favor.
Kenobi:
WebBeans seria uma boa resposta a tudo isso junto… em 80% dos casos de aplicações pequenas/medias…
Eu não generalizo o uso do Spring, muito pelo contrário, reconheco o tamanho deste framework… mas não é por isso que vou colocar ele em tudo quanto é buraco… é só isso…
Quanto as pessoas que mencionei conhecer, será que elas conhecem superficialmente ou só conhecem essa resposta ? tanto que só enchergao a “solução spring” em tudo quanto é lado… mesmo que isso seja condenar todo um densenvolvimento a bilhares de XML’s como era antigamente ( quanto as annotations eu uso o spring annotations faz um bom tempo… e nao me preocupava muito com os XML’s do spring )
E finalizo por aqui essa discussão que admito já perdeu o foco
[quote=Luca]Olá
[quote=leandrokjava]mas pq muita gente vai preferir não usar JSF?
depois que conheci JSF, nunca mais quis voltar para Struts.
[/quote]
Quando conheci JSF (na versão 1.0), fiquei com a impressão que da Sun dificilmente sairá algo que preste em termos de desenvolvimento web. Será que um dos motivos é que o criador do Struts 1.x trabalha lá?
[]s
Luca[/quote]
Bom acredito que sim, de acordo com este este topico http://www.guj.com.br/posts/list/3804.java é oque parece.
mas em nenhum momento falei que Não gosto de Struts só prefiro JSF.
e um viva para Craig McClanahan’s. \o/
Não gosto muito de bater em cachorro morto não …
EJB3 Alive, EJB2.x Dead
Creio que ainda há muitos projetos que usam EJB2.x.
Mas se a idéia for migrar de um pra outro dá pra matar uns 80% só de código inútil :shock:, só aproveitando as regras mesmo.
Na minha opinião navegar em código feito com EJB2.x é um trabalho muito chato, portanto EJB3 Alive (pelo menos em projetos onde é necessário).
Infelizmente ainda tenho que usar EJB2 em muitos projetos legados… mas tenho usado sempre EJB3 quando temos a oportunidade de definir a arquitetura da aplicação.
Luca, Kenobi, chun e demais!
Estou precisando de uma ajuda e creio que vcs podem me ajudar.
Gostaria de informações (benchmark) de cases onde o EJB 3 foi utilizado e esteja atualmente em produção. Trata-se uma pesquisa para corroborar junto à gerência a probabilidade de sucesso da implementação da tecnologia.
Os mesmos se propõem (se for possível) entrar em contato com as empresas que tenham esses cases de sucesso.
Obrigado!
Creio que exista maior utilização de EJB2x, pois o há um considerável custo ($$) para migrar e aderir ao EJB3. Os projetos mais recentes estão aderindo melhor a versão 3.x.
Já usei EJB 3, mas acabei de voltar para o 2.1
Vc voltou por que não gostou ou por que foi obrigado?
[]'s