Primeiramente, queria parabenizar as pessoas dessa thread por conseguir gerar três páginas de conteúdo sem descambar pra idiotice ou pra agressão pura e simples (algo que está sendo raro ultimamente).
Mas indo à discussão, gostaria de expressar a minha opinião sobre as tecnologias citadas anteriormente:
:arrow: EJB3
Por EJB2 ser considerado uma unanimidade em quesito ruindade, fazer comparação entre esta e o EJB3 faz com que esse último aparente ser a última bolacha do pacote. Porém, tenho algumas restrições:
a) Por que a existência de inteface local e remota? Isso não poderia ser resolvido automaticamente? Do tipo: (o bean tá no mesmo nó) ? local : remoto.
b) Por que a anotação @EJB só funciona em Servlet, em Managed Bean ou eu outro EJB? E os outros objetos? Apelam pro Context?
c) Será que adianta correr o risco de de fazer um Big Design Up Front, colocando EJB porque se espera que, quando precisar escalar, basta “simplesmente” trocar tudo pra Remote (e torcer pra não reter ou transferir grande quantidade de bytes)?
:arrow: JSF
Sozinho, o Faces não faz verão. Precisa de uma porrada de bibliotecas e frameworks complementares para que fique algo decente. Nada contra, contanto que as pessoas se convençam de um simples fato: se quer algo completo, não use JSF!
:arrow: Seam
Olhando o que Seam faz, parece uma revolução. Mas não caio de amores tanto assim porque:
a) A anotação @Name me deixa com o pé atrás. É fácil declarar um managed bean desse jeito, concordo. Mas me dá uma sensação de estranheza quando a declaração de instância e a declaração de classe estão coladinhos, um embaixo do outro. Posso estar sendo careta, mas pra mim classe e objeto são coisas distintas e devem ser declarados em locais separados, juntá-los força uma relação nociva de 1 para 1 entre instância e tipo.
b) Seam é difícil quando o container não é o JBoss. Olha, tentei configurar sobre Glassfish v2, e não consegui rodar nem Hello World direito. No JBoss, consegui graças ao Sean-Gen, mas dá aquela sensação: “Não é assim uma Brastemp (ou melhor: um Rails)”.
c) Anotação é legal, mas precisa ser um framework onde o desenvolvedor tem que colocar TRÊS ou QUATRO anotações uma classe? Estamos trocando a era do XML hell para o Annotation hell!
:arrow: Spring
Já tive “nojinho” de Spring. Mas ultimamente estou gostando mais dele. A razão é que o framework está abrindo as portas para anotações e uma solução Faces, Spring e Spring WebFlow é mais simples que Seam com jBPM. Spring tem o problema de XML, mesmo usando autowired; mas a grande gama de serviços oferecidos, e ainda o fato de os grandes frameworks oferecerem suporte a Spring, compensa seu uso.
:arrow: Groovy
Desculpe-me aqueles que gostam dessa linguagem, mas Groovy é o C++ dos novos tempos! Assim como C++ tentou conciliar o paradigma OO de alto nível com o paradigma de proximidade de máquina, o Groovy tenta conciliar uma característica dinâmica com uma linguagem estática. O resultado é um só: complexidade. E é fácil reparar nisso, lembro de um programa C++ em que se abria um arquivo com fopen ao invés do iostream porque o programador simplesmente não conhecia profundamente C++. Com Groovy, um programador que também não tenha muitos conhecimentos pode simplesmente ser tentado a fazer algo parecido com Java, mesmo que não seja a melhor solução.
Além disso, a escolha de Groovy por alguns fãs de Java é puramente ideológica! Já viu alguém desse fórum reclamando pra um rubista que Django (Python) ou CakePHP (PHP) é melhor que Ruby on Rails em determinado aspecto? Lógico que não! Alguns aqui escolheram Grails porque, de todos, é “o que tem mais Java, e se tem Java é bom”. Concordo que com Grails, a integração com Java é mais fácil, mas é um pensamento de curtíssimo prazo! Daqui a pouco, outras linguagens terão integração com Java e serão mais rápidas, fazendo com que a vantagem do Groovy desapareça, sendo apenas lembrado como o mais complicado das linguagens dinâmicas.
