quarta-feira, 12 de agosto de 2009

Reator (ORM Railo Framework)

1. Motivação
.diminuir o tempo de desenvolvimento e manutenção de operações de persistência em banco
.ganhar idependência do banco de dados
.diminuir erros causados pela repetição (sem pensar)

Design patterns ajudam mas não resolvem (DAO com tabelas)
.muito código e arquivos e muita repetição (para cada entidade)...

Database abstraction generators (xmls com o mapeamento)
O que hibernate faz com os arquivos de configuração + camada de acesso aos dados (DAO)

2.Reactor (Inline Dynamic Database Abstraction API)
http://trac.reactorframework.com
.gera objetos só quando necessários
.nao gera controllers
.usa xmls nao convenções
.aceita querys do tipo OO e convencionais

examplo de uso (igual ao orm do cf9???):
//chamada de metodo para criacao de objeto


Realmente fácil de criar métodos de acesso as classes (objetos, coleções, coleções com where = campo escolhido)
Utilizam o padrão Gateway.

Relacionamentos (hasOne e hasMany)
Objetos ficam com "bags" de outros objetos (como no hibernate)

O arquivo de configuração do framework eh semelhante ao xml do hibernate

3. Trabalhos futuros
.Integração com o Amazon Simple DB (investigar o que é)
.Suporte ao hibernate (quando a Ralio decidir)
.Soft delete / ignore columns, IBO (??)
.Criação de tabelas por definições (caminho inverso)
.framework de validação (emails e essas coisas)
.getByFilter (chamada de método passando os valores dos campos para filtrar)
.Injeção de dependência (http://en.wikipedia.org/wiki/Dependency_Injection) para melhor integração com o ColdSpring

4. Minha impressão
Só vale a pena usar se tiver que usar o CF8 e realmente estiver afim de usar ORM. Dá menos trabalho do que a gente viu, mas não sei se na hora que os problemas aparecerem vamos ter mais dor de cabeça....Com o CF9 (ORM) acho que esse framework fica meio obsoleto...

Parece um hibernate só pra coldfusion.

O tempo para desenvolvimento da camda de persistência é realmente rápido e com pouco código.

Pros:
.É interessante pois não precisamos de criar métodos para cada entidade (CRUD + coleções com wheres = campo escolhido)
.Open Source

Cons:
Usando a solução padrão de ORM do CF9 ganhamos:
.controle fino da aplicação, se preciso
.suporte maior a documentação para resolver problemas
.mesmo mapeamento para CF e Java caso seja preciso
.novos frameworks surgirao em cima desta feature, talvez o proprio mude
.Open Source

Nenhum comentário:

Postar um comentário