Não entendi o que metodoloias áeis de desenvolvimento têm a ver com o tópico, e como já dissemos aqui acho que ninguém realmente acredita que Rails vai tomar todo o mercado de Java -ele vai er tomado por diversas coisas em paralelo- mas a menos que se morra em cinco anos eu acho muito difícil as coisas demorarem tanto assim. Java chegou ao status atual há apenas alguns anos e cm muita luta de uma grande comunidade, cmunidade esta que hoje em dia continua lutando por outros ideais, frutos da evolução da indústria (ou da volta no tempo se considerarmos que não ha nada de realmne novo nisso tudo).
Antes de mais nada, gostaria de dizer que, numa arquitetura distribuída, minha preferência é por usar EJB3.
O fato de EJB3 necessitar muito mais conhecimento técnico me parece uma vantagem do Spring. Afinal, o objetivo dos frameworks é diminuir o tempo que o implementador gasta com linhas de código que não resolvem o problema do negócio, certo?
Em uma aplicação Spring com ‘n’ Beans, e uma aplicação com EJB2, com a mesma quantidade de EJB’s, os descritores em XML dos EJB’s eram maiores que o XML do Spring. Eu digo por experiência própria, de ver uma aplicação sendo construída com Spring + EJB na camada de negócio. (Sim, era uma arquitetura do Bozo, aproveitando o pior de cada framework, mas isto está fora da questão aqui). Enfim, pra cada Interface de serviço, tinha um EJB, e dois beans Spring. O XML do Spring era muito menor que os vários XML de descrição dos EJB’s.
Mas enfim, na época a gente usava XDoclet tanto pra gerar o XML do Spring, quanto os descritores dos EJB’s. Mas só os descritores de EJB deixavam a equipe toda parada durante horas, de tempos em tempos, até descobrir quem tinha subido no controle de versão alguma descrição de EJB errado. O servidor de aplicação não subia mais, e não informava qual era o EJB errado. (A aplicação tinha mais de 300 EJB’s, e muita dependência entre eles).
Eu me lembro muito pouco das aulas de sistemas distribuídos na faculdade, mas me lembro que um fator fundamental era transparência de localidade. Ter duas interfaces fere este princípio. E mesmo que em alguma situação de implantação específica se queira duas interfaces, o correto seria o framework permitir o uso de duas interfaces, e não exigir. Realmente, sempre achei isso errado no EJB. Se você usar Spring na interface local, e EJB para disponibilizar a interface remota, você consegue isso.
O NetBeans 6 já trás consigo algumas facilidades neste sentido, e com certeza outras ainda virão.
Passei o sábado desenvolvendo uma aplicaçãozinha RoR com o NetBeans, pra conhecer um pouco mais os recursos que ele oferece pra desenvolvimento Ruby/Rails, e não achei ruins não.
Acho que vale a pena avaliar…
Olá Pessoal,
Visualizei muitos comentários interessantes postados até aqui.
Não sabia que o RoR pretende tomar o lugar do java… 
Então,
A discussão SpringXEJB é muito mais que uma argumentação de pontos
tecnológicos… é praticamente um debate religioso. Tanto o EJB3
quanto o Spring têm pontos interessantes e atendem à determinadas situações.
Um dia a comunidade de desenvolvimento software talvez venha a entender
que a tecnologia é útil para resolver problemas tecnológicos de algum
projeto específico. Ponto. Primeiro é necessário conhecer o problema,
depois propor uma solução. Isto não pode ser invertido.
Eu tenho minhas preferências em termos de tecnologia baseado
naquilo que obtenho através da experiência, isto é, no dia a dia
descubro aquilo que é bom, pontos positivos e negativos, etc.
Todo framework e linguagem possuem pontos fortes e fracos…
Quem pode me dizer alguma solução perfeita? Se disser, está mais para uma
crença que um fator epistemológico.
Spring, EJB3, RoR nunca serão a última bolacha do pacote. Isso não existe.
Mas sobre o Spring X EJB:
Porque motivos eu preciso distribuir uma aplicação se eu nem sei se num futuro
tão próximo precisarei de tal recurso?
Usar EJB simplesmente para ter uma arquitetura n-camadas é plausível? Mesmo
que não seja distribuido? Será que é a única solução?
Ah…posso querer montar um cluster no futuro, e com EJB fica mais fácil…
Tenho que ter DI na minha aplicação? é obrigatório? vai facilitar alguma coisa?
Farei AOP? Realmente preciso ter um mentor transacional?
Pois é…tudo depende.
Sobre os argumentos do pessoal:
Concordo com o Leonardo sobre o EJB, a interface deveria ser comum. Deveria permitir
extensão e não obrigar. Gosto mais da idéia de usar um proxy para
aumentar/diminuir visibilidade.
Por enquanto é isso.
Att.,
Ou o Java acaba com o Spring ou o Spring acaba com o Java. Pode prestar atenção, as principais críticas feitas ao Java não são problemas do Java, mas sim de frameworks imbecis assim como esse Spring.
O Spring é uma aberração, uma coisa horrorosa, uma forma doentia de se trabalhar. Onde já se viu declarar toda a sua aplicação em XML? Isso nem sequer faz sentido!
Por favor elabore mais o problema com o select ao qual você fez referência. Qual é a conexão entre antigos templates de tiles e o JSF para que você deduza que eles devem funcionar perfeitamente? Complicado como exatamente?
A minha experiência com JSF é que ele é umas 100 vezes mais simples que Struts.
Me mostre aí o código simples que você tem pra carregar um select com uma entidade, postar esse valor receber um objeto do outro lado usando JSF. O meu aqui precisa de 1 converter, 1 managed bean que tenha como propriedade a lista dos objetos, mas é óbvio que eu não posso simplesmente retornar a lista de objetos, porque o meu converter vai transformar cada objeto em um número, o id do próprio objeto, então eu tenho que além de pegar a lista, ir de objeto em objeto e colocar ele dentro de um SelectItem pra poder mostrar no maldito select com um label.
Se você conhece algum jeito, ilumine a minha ignorância porque eu não sei de nenhum.
Sobre os templates do tiles, todos os projetos que eu estive envolvido desde que comecei a programar precisavam de templates padronizados e eu nunca gostei de usar includes, então logicamente o modo mais simples de se fazer isso seria usando Tiles ou SiteMesh. Se isso é uma funcionalidade tão comum, JSF deveria vir com um meio de se fazer isso por padrão, afinal deveria ser uma biblioteca pronta pra uso, não pra ficar criando extensão até pro básico, até porque Facelets existe desde que JSF se tornou “real”.
Sim, e quem liga pro Struts 1.x?
[quote=Maurício Linhares]Me mostre aí o código simples que você tem pra carregar um select com uma entidade, postar esse valor receber um objeto do outro lado usando JSF. O meu aqui precisa de 1 converter, 1 managed bean que tenha como propriedade a lista dos objetos, mas é óbvio que eu não posso simplesmente retornar a lista de objetos, porque o meu converter vai transformar cada objeto em um número, o id do próprio objeto, então eu tenho que além de pegar a lista, ir de objeto em objeto e colocar ele dentro de um SelectItem pra poder mostrar no maldito select com um label.
Se você conhece algum jeito, ilumine a minha ignorância porque eu não sei de nenhum.[/quote]
Primeiramente, converters são necessários apenas em situações especiais e não em todas. Da forma como você coloca parece que é assim toda a vida e isso o impediria de fazer algo.
Segundo, qual é a forma correta então de se trabalhar? Elabore mais o seu texto, e diga também como o JSF como um todo é “uma cagada” assim como você disse anteriormente.
Que eu saiba o com modelo de componentes é justamente para permitir que a extensibilidade do JSF. Os componentes com os quais ele foi lançado foram apenas o básico do básico para desenvolvimento web, mas sempre foi esperado que houvesse o desenvolvimento de outros por terceiros com mais funções. A sua premissa de “pronta para uso” é falsa.
Segundo, existem soluções para templates que não são “includes” de JSP, eu sei porque as uso. Mas da forma como você disse mais parece que era obrigação dos desenvolvedores deles usar justamente aquela que você deseja e nenhuma outra.
Sim, e quem liga pro Struts 1.x?[/quote]
Uma boa parte do mercado que ainda pede conhecimento nessa porcaria, só. Pouca gente, né?
Então um simples select é uma situação especial? :lol:
JSF é usável quando vem com Seam, Facelets e Ajax4jsf/RichFaces/IceFaces, sem isso é uma montanha de complicações inúteis. Chega a ser engraçado ver as tags de apoio do Seam como a dos select itens e a entity converter, você olha, olha, olha e não acredita que JSF não tem isso por padrão, por mais simples que fosse fazer.
Até o próprio Craig McTananã já sabia que o negócio era complicado e já começou o Struts Shale pra ajudar os pobres desenvolvedores JSF, porque o que ele estava fazendo por fora não entrou no padrão? Porque o padrão é tão fraco? Porque o esquema de renderização de componentes ignorou por completo a possibilidade de se utlizar ajax em aplicações jsf?
Se você acha bom, ótimo, continue programando com JSF no braço, eu detesto e não indico esse suplício a ninguém.
[quote=Thiagosc]Que eu saiba o com modelo de componentes é justamente para permitir que a extensibilidade do JSF. Os componentes com os quais ele foi lançado foram apenas o básico do básico para desenvolvimento web, mas sempre foi esperado que houvesse o desenvolvimento de outros por terceiros com mais funções. A sua premissa de “pronta para uso” é falsa.
Segundo, existem soluções para templates que não são “includes” de JSP, eu sei porque as uso. Mas da forma como você disse mais parece que era obrigação dos desenvolvedores deles usar justamente aquela que você deseja e nenhuma outra.[/quote]
Foi mal, mas ASP.NET (daonde eles diziam que estavam se inspirando) já tem isso há muito tempo, isso é básico pra qualquer framework se preocupe com a camada de visualização na web. Mas voltemos a nossa premissa de “pronto pra uso”, quer dizer que o JSF não era pronto pra uso? Tinha que vir a galera pra criar extensões e deixar ele útil? Quer dizer que JSF purinho não serve pra nada?
:lol:
Tá ruim mesmo viu
Mais uma vez, e daí?
Não estamos comparando market share aqui, o que você disse era que JSF era mais simples do que Struts 1.x, o que eu estou dizendo é que o Struts 1.x deixou de ser parâmetro de comparação pra simplicidade a muito tempo, JSF tem que ser comparado com frameworks atuais como Wicket, Struts 2, VRaptor e seus contemporâneos. Struts 1.x só existe em quem deixou o trem do tempo passar ou não tem política nenhuma de atualização ou migração de tecnologias.
Só para organizar melhor a argumentação das minhas últimas mensagens:
1- As críticas do Maurício Linhares são superficiais demais. Por exemplo, não há problema algum em usar selects, ou qualquer outro componente, com datas e números. Para se adicionar um objeto qualquer criado por você mesmo é necessário fazer um converter, que consiste apenas em uma interface com 2 métodos (se me recordo corretamente, getAsObject, getAsString). O que me parece ser razoável visto que o framework não tem a obrigação de conhecer o seu modelo de classes;
2- Existem várias implementações e bibliotecas para extender o JSF. Só usa JSF “purinho” quem quer;
3- O modo de desenvolvimento do JSF é bem fácil se comparado a outros frameworks. Foge totalmente do modelo de Servlets (recebe request -> processa lógica -> repassa para outro servlet ou JSP) e se assemelha mais com desenvolvimento desktop, embora não seja a mesma coisa. Basta associar métodos e propriedades com botões, links e campos. Os ManagedBeans apenas contém esses métodos e campos. Validação e conversão também são simples;
4- Levando-se em consideração que o JSF é parte do Java EE e já conta com várias bibliotecas disponíveis e vem crescendo, se tivesse que apostar eu apostaria nele;
Eu sempre questiono os sabichões porque o JSF é odiado pelo fanáticos opensource quase como uma unânimidade, e quase sempre eles não sabem dizer o por quê.
[quote=Thiagosc]
Ou o Java acaba com o Spring ou o Spring acaba com o Java. Pode prestar atenção, as principais críticas feitas ao Java não são problemas do Java, mas sim de frameworks imbecis assim como esse Spring.
O Spring é uma aberração, uma coisa horrorosa, uma forma doentia de se trabalhar. Onde já se viu declarar toda a sua aplicação em XML? Isso nem sequer faz sentido![/quote]
Thiagosc,
Por este raciocínio, poderia-se esperar que J2EE teria enterrado Java. Foram as especificações J2EE que criaram a idéia de declarar toda a aplicação em XML.
Eu também não sou fã da extensa configuração em XML que marca a história da J2EE. Mas implementação de Spring apenas seguiu a tendência de Java de “configuration over convention”. E o Spring fez um trabalho muito melhor do que a especificação de EJB 2.1, inclusive no que se refere à verborragia em XML.
Além disso, Spring popularizou o conceito de POJOs e injeção de dependência, e convenceu o mundo Java, já que a tendência atual é valorizar estes conceitos.
Como já disseram nesta thread, cada framework tem seus méritos e seus problemas. O avanço do EJB3 se deve aos resultados atingidos pelo Spring.
Sendo assim, Spring não vai contribuir para enterrar o Java. Spring serviu para ajudar a evoluir o Java, e os conceitos de programação como um todo. Muito provavelmente Spring vai acabar antes do Java, mas ainda vai existir por algum tempo, rivalizando com a especificação, forçando a uma evolução constante da mesma, assim como o próprio Spring aprendeu com a especificação EJB 3.
Além disso, cada framework que existe foi criado para resolver algum problema do Java, o que mostra que Java e J2EE tem muitos problemas.
[quote=canabrav]Por este raciocínio, poderia-se esperar que J2EE teria enterrado Java. Foram as especificações J2EE que criaram a idéia de declarar toda a aplicação em XML.
Eu também não sou fã da extensa configuração em XML que marca a história da J2EE. Mas implementação de Spring apenas seguiu a tendência de Java de “configuration over convention”. E o Spring fez um trabalho muito melhor do que a especificação de EJB 2.1, inclusive no que se refere à verborragia em XML.
Além disso, Spring popularizou o conceito de POJOs e injeção de dependência, e convenceu o mundo Java, já que a tendência atual é valorizar estes conceitos.[/quote]
Discordo. A única coisa monstruosa que o J2EE tinha era EJB. O XML do Servlets era chato, mas era mínimo. Na época, em comparação com as opções que existiam (Perl, ASP, etc), o Java realmente era uma melhor opção.
E parem de viver no passado. Até quando usarão o EJB 2.x como exemplo?
Bom para o EJB, mas o Spring continua sendo terrível. O problema do Spring não é conceito de IoC em si, mas sim como é implementado. Parece mais uma forma de permitir que desenvolvedores Java façam coisas que em outras linguagens seria possível. Parece mais um workaround muito tosco em volta de alguma limitação da linguagem.
[quote=canabrav]
Sendo assim, Spring não vai contribuir para enterrar o Java. Spring serviu para ajudar a evoluir o Java, e os conceitos de programação como um todo. Muito provavelmente Spring vai acabar antes do Java, mas ainda vai existir por algum tempo, rivalizando com a especificação, forçando a uma evolução constante da mesma, assim como o próprio Spring aprendeu com a especificação EJB 3.[/quote]
Você não entendeu o que eu quis dizer. Quando disse que o Spring acabaria com o Java, não era por causa de uma concorrência, mas sim por impor um modo de desenvolvimento tão terrível como “padrão” que automaticamente fará todos correrem para o Ruby ou Python ou qualquer outra opção que pareça sã.
Aprendamos com a Microsoft. Não precisamos de cem frameworks, precisamos apenas de um que funcione.
[quote=Thiagosc]
…
Aprendamos com a Microsoft. Não precisamos de cem frameworks, precisamos apenas de um que funcione…[/quote]
Ué! Microsoft…um que funcione… de qual framework você esta falando? :twisted:
O XML da especificação servlet é mínimo? :shock: Acho que se você não usar nada da especificação, tudo bem. Mas se usar servlets, filters, eventos, taglibs, segurança, etc. tem muito XML. Mas normalmente todo mundo foge de usar muita coisa da especificação, preferindo outros frameworks, ou outros mecanismos. Talvez por isso você ache que o XML seja mínimo.
1- Você defende o JSF comparando com Struts 1.x, argumentando que ainda é muito usado no mercado. Bom, te digo que tem muita empresa ainda desenvolvendo com EJB 2.x também. E não deve parar tão cedo. Veja que ainda tem muita empresa desenvolvendo em Java 1.4
2- EJB 3 possui injeção de dependência. Se você não gosta deste mecanismo, então EJB3 também não presta. Você prefere EJB3, ou EJB2? Como você recomenda implementar sua camada de serviço em Java?
Então, você concorda que o problema está na linguagem Java. E como eu disse, Java tem muitos frameworks, porque tem muitos problemas.
Eu acredito que o melhor framework já feito em Java se chama Servlet API. Não porque seja o melhor framework para aplicações web, mas porque é bem documentado, bem testado, tem uma implementação de referencia bem-feita, tem suporte, etc. Graças a ela que esses 10 milhões de frameworks web em Java puderam aparecer.
E se você está usando muito XML você deve estar usando o framework errado. Use Stripes por exemplo que você poderá fazer tudo via annotations com a menor configuração possível.
[quote=Thiagosc]
Aprendamos com a Microsoft. Não precisamos de cem frameworks, precisamos apenas de um que funcione.[/quote]
Sim, apenas uma maneira de se fazer qualquer coisa, formando uma monocultura que, quando desaba, leva todos junto com ela.
Sim, pensar de apenas uma maneira, fazendo com que você fique totalmente bitolado e que, quando precise trabalhar com outra ferramenta, se sinta completamente perdido.
Sim, apostar em apenas uma maneira de fazer tudo para que todas as aplicações criadas pela plataforma pareçam idênticas.
Sim, aí nós vamos poder seguir o mesmo caminho seguido por uma legião de programadores que trabalhavam apenas com VB6 (visto como um “único framework que funciona bem”) que, de um dia para outro, se viram totalmente abandonados e hoje estão, em sua maioria, totalmente defasados tecnológicamente por terem apostado em um “único framework que funciona bem”.
E, mais curioso ainda, usando algo que a própria criadora não usa (.net).
UOU! Quanta coisa pra “aprender” com a Microsoft!
Na minha opinião, o argumento de que você deve ter apenas um framework, e que este funcione bem, é argumento de gente que tem PREGUIÇA de aprender.
A própria Microsoft reconheceu que só WebForms não é a solução para todos os problemas e criou o Web MVC, baseado na estrutura do Rails, para o novo Visual Studio.
Eu sei que é difícil acreditar, mas eles não erram sempre. Aliás, o movimento ALT.NET está cada vez mais forte, e o novo runtime tem uma série de facilidades que estão muito à frente do que existe hoje em Java.
[quote=rubinelli]A própria Microsoft reconheceu que só WebForms não é a solução para todos os problemas e criou o Web MVC, baseado na estrutura do Rails, para o novo Visual Studio.
Eu sei que é difícil acreditar, mas eles não erram sempre. Aliás, o movimento ALT.NET está cada vez mais forte, e o novo runtime tem uma série de facilidades que estão muito à frente do que existe hoje em Java.[/quote]
A Microsoft criou porque sua cultura é ditada pela mesma. É e sempre foi assim. Pegue um framework de terceiros e veja qtos usam no .NET. NHibernate é um caso, raramente um profissional usa, e sabe porque? Porque não foi feito pela M$.
Java tem cultura diferente, a comunidade faz, as pessoas começam a usar, vira hype e então a Sun chama os criadores ou estes se candidatam para melhorar uma parte da especificação.
Vi esse MVC da microsoft e sinceramente, se não fizessem, seriam engolidos pela concorrência. Até hoje não tinham nada em comparação. Já o Java tem o JRuby que roda Rails e Grails (que está sendo adotado pela SAP). A isso chamo de mercado da concorrência 
.
Abraço
Eles contrataram o desenvolvedor do Jython para criar o IronPython, e o criador do DAL SubSonic para integrá-lo como ORM do MVC. O IronRuby ainda não chegou a uma versão estável mas também está em desenvolvimento. Java realmente tem uma cultura mais forte de compartilhar código, mas a Microsoft tem a vantagem de não depender de um processo decisório que normalmente leva anos para chegar a uma resolução.