Adicionando a lista…
ps. Pelo menos no site eles dizem que são.[/quote]
Tem o Grails também.
Adicionando a lista…
ps. Pelo menos no site eles dizem que são.[/quote]
Tem o Grails também.
Full-stack é o oposto de framework salad. Mas full-stack não significa que vc é obrigado a utilizar a solução do framework. Nada te impede de jogar o jar lá dentro e utilizar Spring, Jakarta Commons, JSTL, etc. Eu particularmente não gosto de projetos onde 20 frameworks diferentes são utilizados, e muitos projetos Java são assim e ainda ostentam orgulho em relação a isso.
Vc tocou num ponto crítico. Persistência de dados é uma área onde apesar de haver concorrência há medalhões como Hibernate e ActiveRecord. Dá tranquilamente para utilizar um framework web sem Hibernate e RoR sem ActiveRecord. Mas não dá para recomendar isso devido ao nome (merecido!) que Hibernate e ActiveRecord possuem.
A filosofia do framework sempre foi ser full-stack, desde dos primórdios.
O problema que vejo não é a quantidade, é q quantidade que fazem exatamente a mesma coisa com nome diferente.
É errado ter 500 distro linux? não, não vai matar ninguém, mas precisa? até que ponto isso pode ajudar e prejudicar?
Gostaria que as pessoas colaborassem mais com projetos já existentes, sempre tem espaço, se não querem adicionar sua novidade revolucionária, faça um plugin/modulo, não há problema nisso, deixe claro que o seu é o VRaptor with Lasers, usa a base já sólida para adicionar novidades e evoluções.
Acho mais interessante criar um “plugin” para o framework X do que lançar um novo, visto que quase todos só fazem uma miserinha de nada de diferente dos já existentes.
O spring-anottations por exemplo, poderia ser um “fork” lançado como Tabajara MVC Jaspion with Anottation, será que seria interessante para os usuários do Spring “mudar” de framework ou realmente continuar o que já lhes cabe bem mais tendo recursos adicionais que são interessantes pra eles?
Será que java é tão mais poderosa/grande/inovadora pra ter a quantidade de frameworks que tem quando se comparado a Ruby, Python, PHP por exemplo?
É preciso evoluir, não resta dúvida, exatamente nesse caso que vejo que unir-se (colaboram com algo que já existe) pode agregar mais valor.
Essa é a minha visão apenas!
[quote=Luiz Aguiar]O problema que vejo não é a quantidade, é q quantidade que fazem exatamente a mesma coisa com nome diferente.
É errado ter 500 distro linux? não, não vai matar ninguém, mas precisa? até que ponto isso pode ajudar e prejudicar?
Gostaria que as pessoas colaborassem mais com projetos já existentes, sempre tem espaço, se não querem adicionar sua novidade revolucionária, faça um plugin/modulo, não há problema nisso, deixe claro que o seu é o VRaptor with Lasers, usa a base já sólida para adicionar novidades e evoluções.
Acho mais interessante criar um “plugin” para o framework X do que lançar um novo, visto que quase todos só fazem uma miserinha de nada de diferente dos já existentes.
O spring-anottations por exemplo, poderia ser um “fork” lançado como Tabajara MVC Jaspion with Anottation, será que seria interessante para os usuários do Spring “mudar” de framework ou realmente continuar o que já lhes cabe bem mais tendo recursos adicionais que são interessantes pra eles?
Será que java é tão mais poderosa/grande/inovadora pra ter a quantidade de frameworks que tem quando se comparado a Ruby, Python, PHP por exemplo?
É preciso evoluir, não resta dúvida, exatamente nesse caso que vejo que unir-se (colaboram com algo que já existe) pode agregar mais valor.
Essa é a minha visão apenas![/quote]
Acho interessante a sua opinião, mas vejo que os plugins existem de fato. É assim com JSF (principalmente), Struts 2, GWT e Wicket. E existe a possibilidade de utilizar outras estratégias para carregar beans no Spring. Se alguém quisesse fazer, poderia. Não é a ausência de gente que faz plugins o motivo para que o Java tenha vários frameworks, pra mim a razão é outra.
Primeiro, que Java tem um grande mercado, os “stakeholders” são inúmeros e variam de grandes empresas a iniciativas de código aberto. É impossível atender a todos, e cada nicho cria soluções que atendam a seus interesses.
Segundo, que, no universo Java, houve várias “reviravoltas” de como se pode desenvolver software. Inicialmente, se achava que se deveria usar fortemente Design Patterns, e vários frameworks seguiram a tendência de se usar Template Method (EJB 2.x, Servlets e Applets usam esse pattern). Depois, houve a era dos POJOs (Spring, Hibernate, JSF), e nenhuma classe deveria herdar classe de framework, apenas escrever zilhões de tags de XML. Houve um incremento dessa era, onde houve a troca de XML por anotações (JPA, EJB3, Seam). Aconteceu a febre Rails, e o que mais importa agora são frameworks que obedecem ao mantra “convenção sobre configuração”, que novos frameworks buscam seguir (Rails, Grails, Wicket).
E nessa troca de “eras”, os frameworks antigos não deixam de existir, o que acontece são novos frameworks que se acrescentam aos demais.
Olá
Só para provocar: Apresentação do Matt Raible na OSCON 2008 - Web Frameworks
of the Future em http://raibledesigns.com/rd/entry/oscon_2008_web_frameworks_of
[]s
Luca
Saoj,
Dá pra recomendar sim!
Particulamente não sou muito fã de hibernate. Para você ter um desempenho razoável e boa modelagem (questionável), é necessário deixar o controle na mão do Hibernate. E como a maioria das aplicações possuem a modelagem independente, já fica difícil usá-lo, sem contar ainda que para ter sucesso com ele, você tem conhecer MUITO do framework, entrar em picuinhas. Dentre essas e outras, prefiro o bom e velho JDBC. Nada melhor
que ter o controle da aplicação.
ORM não é fácil…tende a ser uma gambiarra.
Abraço,
Saoj,
Dá pra recomendar sim!
Particulamente não sou muito fã de hibernate. Para você ter um desempenho razoável e boa modelagem (questionável), é necessário deixar o controle na mão do Hibernate. E como a maioria das aplicações possuem a modelagem independente, já fica difícil usá-lo, sem contar ainda que para ter sucesso com ele, você tem conhecer MUITO do framework, entrar em picuinhas. Dentre essas e outras, prefiro o bom e velho JDBC. Nada melhor
que ter o controle da aplicação.
ORM não é fácil…tende a ser uma gambiarra.
Abraço,
[/quote]
Concordo com vc em gênero, número e grau. Eu tb só uso JDBC com uma query builder para agilizar as coisas. Mas tem gente que domina e ama o Hibernate, que vai achar isso loucura. Ambas as partes têm razão.
Eu acho que já existem frameworks MVC suficientes