Começamos um novo projeto para nosso cliente e, por causa de alguns detalhes desta app, resolvemos experimentar o SQLite Persistent Objects - SLPO. Já falamos sobre o Active Record - AR - antes e das suas características como ORM para iPhone e agora estamos avaliando o SLPO.

Objetos não-persistidos

Até agora, a principal vantagem do SLPO é permitir a criação de objetos não-persistidos, ou seja, posso instanciar e manipular um objeto a vontade antes de salvá-lo no banco. Isso permite o uso de objetos temporários em telas onde o usuário pode popular uma entidade e, se desejar, cancelar todo o trabalho, sem que isso cause maiores dificuldades na implementação. O AR por sua vez nos obriga a criar value objects iguais a classe da entidade ou inserir os registros imediatamente na base e depois excluí-los se o usuário desistir da criação.

Por outro lado, o AR suporta habilitar ou não o delay writing, ou seja, posso decidir que toda vez que alterar um atributo, ele seja salvo automaticamente na base.

Criação automática da base

Enquanto o AR "deduz" os atributos das classes automaticamente conforme convenções no banco de dados, o SLPO faz o inverso: dados os atributos definidos na classe, o framework cria automaticamente a base de dados, as tabelas e os atributos. Essa abordagem é muito prática se você deseja começar a desenvolver rapidamente e seu modelo entidade-relacionamento é bem simples.

Contudo, como a maioria das ferramentas que automatizam um trabalho de criação, o resultado na base não é tão bem-feito como se fosse desenvolvido por um ser humano. O SLPO cria tabelas intermediárias onde somente uma foreign-key faria o trabalho e quando ele usa alguma foreign-key, esta normalmente é uma string, pois guarda a informação da tabela com que se relaciona.

Outro problema é que fico receoso de mexer na base por conta própria - para acrescentar uma trigger p. ex. - e prejudicar o funcionamento do framework. Já o AR funciona como no Ruby on Rails e utiliza convenções para deduzir nomes de classes, tabelas, atributos e relacionamentos. Conhecendo essas convenções simples, não é muito trabalhoso criar o banco para usar com a app.

Tipos dos atributos

Uma vantagem clara do SLPO é que ele suporta uma quantidade muito maior de tipos. Enquanto, o AR suporta basicamente NSString, NSData e NSNumber (sim, sem primitivas!), o SLPO suporta também UIImage, primitivas - int, float, double, etc - e qualquer classe que implemente o protocolo NSCoding, o que é ótimo, pois permite você persistir suas próprias classes como atributos no banco.

Resumo

Como todo blog que faz uma comparação entre tecnologia faz uma tabelinha, aqui vai a nossa:

	Active Record	SQLite Persistent Objects
Criação automática da base
Definição automática das propriedades nas classes
Objetos temporários
Delay writing opcional
Convenção sobre configuração
Tipos primitivos
Tipos personalizados
Cache
Relacionamentos
Referência	link	link

Existem outras características de cada framework, mas essas foram as principais que serviram para escolhermos o que se adaptava melhor a cada projeto. Se você usou um dos dois, fique a vontade para comentar e contar sua experiência.

Abraço