Nitro - Um novo framework web!

É um outro framework (muito menos conhecido, claro) usado em cima do Ruby, alguns aspectos se assemelha ao rails, e parece que usa o mesmo recurso do record do rails, porém tem mais recursos voltados para web 2.0.

Definição

Página Oficial

Ainda está no início (falta documentação descente ainda), mas quem sabe, pode virar uma forte alternativa a quem quer programar em um novo conceito de framework web.

Nitro é tão velho quanto rails. (Veja data no rubyforge).

A documentação do nitro é péssima. De uns tempos cara cá, George(lider), tem mudado muito o código e parou de gerar documentação. Até onde tenho acompanhado, parece que o pessoal agora vai dar mais atenção a isso.

Quando eu começei a mexer com a persistência do Nitro(Og), eu desencantei totalmente com active record. Percebi um enorme potencial no Og.

Realmente existem várias coisas legais no nitro, eu recomendo brincar um pouco com ele apenas para se livrar da tirania rails ;)

Postando só pra um +1 no inconformismo com o activerecord :(

Sem querer ser apologético mas já sendo. O maior problema não só do ActiveRecord mas de outros ORM são os bancos de dados. Para começar cada um tem peculiaridades que não se consegue mapear no outro, tem funções que outros não tem. Mapear estruturas de dados relacionais em um sistema de objetos hierárquicos nunca foi tarefa fácil. Você pode abstrair demais ou abstrair de menos e o meio do caminho é sempre o mesmo nevoeiro. Até hoje nunca achei um ORM que realmente me satisfizesse. Com frequencia encontramos um caso onde odiamos estar usando o ORM x ou y porque ele torna as coisas mais difíceis e sempre é possível encontrar um exemplo isolado onde um parece melhor do que o outro. Quando se coloca na balança, tanto faz, queremos o trabalho pronto.

Nitro/Og como o antonio disse, existe faz muito tempo. Graças ao Rails esses projetos que estavam esquecidos começaram a se mexer um pouco, o que é sempre bom. Da forma como está hoje o Og não faz muito diferente do ActiveRecord, ainda tem muito menos recursos. O problema não é mapear uma tabela e meia dúzia de campos, o problema é começar a lidar com vários relacionamentos many-to-many, associações polimórficar, diversas queries que precisam de outer joins, subselects, quando você tiver que mapear 100 tabelas cada uma com 20 campos, etc. O ORM mais robusto que existe hoje são EJB3 e Hibernate, ambos fazem mais que o ActiveRecord, mas eu sempre imagino eles como um canhão para matar uma mosca, e eis novamente o problema do balanço.

Conclusão: dentro da filosofia Rails, ActiveRecord hoje é muito prático e atende 80% dos casos. Situações mais cabeludas podem ser contornadas com a já vasta gama de plugins acts_as como has_many_polymorphs. A cada nova versão ele vem amadurecendo, como neste novo 2.0.0 Preview onde ganhou o mecanismo de Query Cache.

dentro da filosofia Rails, ActiveRecord hoje é muito prático e atende 80% dos casos.

Diga-se de passagem isso representa bem a filosofia do Rails.