BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias DataMapper Chega a Versão 1.0

DataMapper Chega a Versão 1.0

Favoritos

DataMapper, um Mapeador do Objeto Relacional (ORM) para Ruby, chegou a um marco recentemente atingindo a versão 1.0. O lançamento, anunciado durante a RailsConf 2010 coincidiu com o tema da apresentação de Dirkjan Bussink na conferência. O DataMapper (DM) é um projeto comunitário que amadureceu nos últimos dois anos. Oferecendo um ORM rápido, com controle de concorrência e rico em funcionalidades. A InfoQ teve a oportunidade de conversar com Dan Kubb, líder do projeto.

O DataMapper teve a versão 1.0 lançada, um passo significante em relação aos lançamentos anteriores a 0.10. Dan ofereceu algumas idéias sobre essa versão:

A escolha para ir para 1.0 foi um tanto difícil. Por um lado você quer que a 1.0 seja pefeita e completa, mas por outro você conclui que software nenhum é completo ou mesmo perfeito, e então você utiliza outros critérios para tomar a decisão. Em nosso caso, nós decidimos que 1.0 sigfinica que a API está estável significando que não estão planejadas nenhuma mudança na API pública que todo mundo usa e nem na API "semipublic" que os autores dos plugin utilizam. Poderão existir adições, mas o ponto principal é que um código escrito para a versão 1.0 da API deve funcionar com poucas mudanças até o lançamento da versão 2.0. Quando o DM foi lançado (há apenas 2 anos atrás), a API estava em fluxo constante, mas nos últimos 6 a 12 meses as coisas se estabilizaram e nós estamos bem felizes em como a API está funcionando agora.

Na realidade o DataMapper 1.0 é provavelmente onde a maioria do projetos open source Ruby estão quando atingem a versão 2.0 ou 3.0. Nós temos um tremenda comunidade ativa por trás do DM, com cerca de 150 gems relacionadas e mais de 1000 desenvolvedores que estão comprometidos com uma ou mais dessas gems. Existem cerca de 40 adapters que permitem que o DM utilize diferentes mecanismos de armazenamento para persistência de dados. Nós temos os RDBMS mais comuns que se espera ter, sistemas NoSQL e até mesmo serviços Web como o Salesforce.

A modelagem do DataMapper nos permite um desacoplamento dos problemas que temos com a persistência da API de front-end que você interage. Isso fornece alguns conceitos básicos para correspondência de objetos, mas os autores de adaptadores são livres para implementar todos ou alguns desses que fazem sentido para o mecanismo de persistência. A maioria dos plugins oficiais do DM não fazem nenhuma suposição particular sobre o mecanismo de persistência que irá ser utilizado e deve funcionar com todos adaptadores.

O DataMapper tem uma abordagem de implementação diferente em relação a outros ORM tais como ActiveRecord, que o Rails utiliza por padrão. Quando perguntado sobre quais funcionalidades um desenvolvedor Ruby pode achar convicente em relação a outros ORMs, ele explicou:

Eu imagino que existem muitas funcionalidades que os desenvolvedores irão achar convincente, mas eu vou começar com a coisa que a maioria das pessoas que trabalharam com o ActiveRecord perceberão razoavelmente rápido é que o DM é declarativo por natureza. No DM cada propriedade e relacionamento é declarado no modelo, e isso é usado como a fonte autoritária ao invés do banco de dados. Você especifíca as restrições e comportamentos em um lugar e tudo é refletido a partir do modelo e usado pelas migrações, validações e outras coisas. Por exemplo, olhe esse caso simples:

class Contact
   include DataMapper::Resource
   property :id, Serial
   property :name, String, :length => 1..30, :required => true, :unique => true
end

Assumindo que você está usando um RDBMS, quando você chamar o DataMapper.auto_migrate! uma tabela chamada "contacts" será criada com duas colunas. A coluna "id" será configurada como chave primária e terá incrementação automática. A coluna "nome" será um CHAR(30), configurada como NOT NULL, e terá um índice único. Em adição, existirão validações configuradas que asseguram que o 'id' e 'name' estão presentes, 'id' é um Integer, 'name' é uma String, o tamanho de 'name' está entre 1 e 30 caracteres, o 'name' não é nulo, e 'name' é único.

No ActiveRecord você precisaria mexer em múltiplos arquivos, lembrando de manter as coisas em sincronia com o banco de dados e as validações que estão sendo desenvolvidas. O que acontece em muitos casos é que os desenvolvedores não se preocupam com tudo aquilo e apenas com as validações, tratando seus banco de dados com um armazenador de dados "burro", enquanto o DM torna aquilo de uma forma simples. Nós encorajamos as pessoas a usarem os poderes do mecanismo de armazenamento adjacentes.

Quando utilizava o AR antes do DM, eu sempre esquecia quais campos estavam no meu banco de dados, então eu executava plugins como annotate_models para adicionar comentários no topo dos meus modelos apresentando o esquema do banco de dados corrente. Na realidade eu estava exatamente duplicando o que você declara no DM, exceto os benefícios... Eu ainda precisava especificar todas minhas validações e migrações iniciais.

A popularidade do Ruby on Rails 2.x e com sua completa reescrita para a versão , o assunto de integrar DM com Rails veio a tona. Qualquer desenvolvedor pensando em se desviar do caminho “normal” de fazer as coisas precisa pesar os possíveis benefícios da mudança do ActiveRecord versus o quão fácil será a implementação. Nós discutimos o uso do DM com Rails:

Existem poucas pessoas trabalhando com DM e Rails 2 e 3 e isso tem funcionado muito bem. A gem para Rails 2.x se chama rails_datamapper, e a gem para Rails 3 é a dm-rails. Nós decidimos em dividir os plugins em 2 ao invés de suportar Rails 2 e 3 em uma mesma gem devido ao rápido desenvolvimento que está acontecendo no Rails 3, e para assegurarmos que estamos em sincronia com ele. Vários desenvolvedores DM monitoram as mudanças no Rails 3 e asseguram que o dm-rails funcione perfeitamente com ele.

Nosso foco principal no momento é definitivamente ter o DM 1.0 funcionando com o Rails 3 assim como ele funciona com o ActiveRecord. O time do rails-core tem se esforçado bastante para fazer o ORM do Rails 3 bem agnóstico, e trabalharam com o time principal do DataMapper para assegurar que acertamos os pontos necessários para ter tudo funcionando perfeitamente.No passado, com o Rails 2, tivemos que fazer muitos hacks para integrar as partes, mas esse não é mais o caso.

Nós estamos realmente muito felizes em como dm-rails está se desenhando, e no futuro algumas de suas “façanhas” serão refatoradas para uma gem que poderemos usar em todos os frameworks web fornecendo tarefas rake consistentes, (re)carregamento dos objetos de modelo, etc. Isso permite que, a ligação para fazer o DM funcionar com cada framework web, ser ainda mais simplificada.

A idéia de usar DM no lugar do ActiveRecord em um projeto Rails cria questões sobre o quanto fácil é para um desenvolvedor se adaptar as convenções usadas por um ORM alternativo. Nós queremos a certeza que o DM substitui completamente o projeto ActiveRecord e não é apenas um complemento:

Sim, correto. Com o DM, você inclui um módulo em suas classes existentes. A maioria das buscas do AR tem uma equivalente no DM, e, em alguns casos, a equivalência é mais simples do que com o AR. Nós temos suporte para as mesmas validações, e existem cerca de 150 gems relacionadas com o DM disponíveis. Embora a sintaxe seja diferente em alguns casos, estou bastante confiante que o DM pode fazer tudo o que o AR faz sem nenhum plugin.

Uma das funcionalidades mais legais do DM é como todas as propriedades e relacionamentos são declarados no modelo. Isso é um indício que as migrações do Rails não são mais necessárias. Dan rapidamente esclareceu o por que as migrações ainda são necessárias:

Isso é parcialmente verdade. Migrações ainda são necessárias uma vez que sua aplicação vai para produção, porque você tem que dizer ao banco de dados como ele se muda preservando a informação. Coisas como a migração automática são destrutivas pois elas derrubam todas as tabelas e criam novamente para ficarem de acordo com o modelo corrente de objetos, e a atualização automática adiciona novas tabelas, colunas e índices mas não é esperta o suficiente para fazer coisas como renomeação e exclusão de colunas ou decompor uma coluna em mais de uma coluna. Eu não estou completamente convencido que será possível lidar com esses tipos de coisa de uma forma esperta sem explicitar o que você precisa em uma migração.Entretanto, eu imagino que as migrações podem ser simplificadas se você utilizar as atualizações automáticas como parte de seu processo de migração para lidar com mudanças aditivas, e usar as migrações explícitas para lidar com os casos de remoção e ambíguos.

Como dito, estamos considerando uma forma de *gerar* migrações que podem ainda simplificar mais as coisas. Deve ser possível perceber a diferença entre dos objetos do modelo e o banco de dados e gerar as migrações que executam as mudanças. O desenvolvedor teria que verificar as migrações para ter certeza que é aquilo que ele quer e depois executá-las, mas escrever migrações é provavelmente algo que você não precisará mais fazer. Concluindo, nós estamos lidando com as mudanças aditivas, destrutivas e ambíguas deixando para o desenvolvedor um esforço mínimo.

O DM introduz o conceito de migrações automáticas oferencedo ao desenvolvedor algumas vantagens sobre as migrações típicas do Rails:

Para um desenvolvimento rápido isso é definitivamente um grande ganho. Ter a possibilidade de fazer o TDD e apenas trocar entre os objetos de modelo e as especificações para adicionar novas propriedades ficou tão mais fácil do que se mover entre os objetos de modelo, as migrações e espeficicações, e então, quebrar seu fluxo para mudar uma tabela e então aplicar as mudanças no banco de dados.

Um dos aspectos mais atrativos desses tipos de projeto para os desenvolvedores deve ser a abundância de plugins, os quais podem ser usado com o DM para adicionar funcionalidades. Esses plugins incluem acessar vários armazenadores de dados como CouchDB, armazenamento REST e Google AppEngine. A habilidade de usar o DM para acessar os armazenado do Google AppEngine é muito interessante, permitindo os desenvolvedores criar aplicações executadas pelo JRuby na infraestrutura do Google.

Eu tenho me envolvido pouco com o dm-appengine-adapter por isso eu provavelmente não tenho muitos detalhes sobre ele. Eu conversei com John Woodell, que trabalha no projeto AppEngine no Google, em algumas conferências sobre o adapter e os desafios que acompanharam o desenvolvimento da API do adaptador DM.

Pelo que o ouvi o adaptador está funcionando muito bem, e suporta a maior parte do sistema de consultas do DM. Pelo ponto de vista do Google esse é um ganho sobre desenvolver um próprio mapeador de objetos para o AppEngine, eu sei que iniciaram com um projeto chamado Bumble, mas até onde eu sei ele nunca ganhou força. O DM tem uma grande comunidade de desenvolvedores, e muitos plugins e o único desafio foi desenvolver o adaptador inicial, e, pelo que ouvi, isso não foi tão difícil. Eu certamente desenvolvi adaptadores DM para sistemas de armazenamentos específicos em pouco tempo.

Isso me lembra um benefício do DM que poucos falam a respeito. A cada novo sistema de armazenamento adicionado ao DM, o time principal é avisado e então esse novo sistema é adicionado no próximo lançamento da API do adaptador. Então, cada adaptador que é criado torna fácil a adição de mais adaptadores com mais capacidades. Por exemplo, existe um trabalho corrente para o adaptador do MongoDB, e ele tem alguns conceitos que não são suportados pelo DM. O desenvolvedor desse plugin está ajudando o DM a suportar isso. Coisas como os Embedded Resources do Mongo podem ser implementados usando algo chamado Embedded Value, e isso deve funcionar muito bem com todos os adaptadores existentes.

O DataMapper não foi criado para ser especificamente usado pelos desenvolvedores Rails, nós queremos saber que tipo de desenvolvedor é alvo do DM:

O DM mira no desenvolvedor que percebe que no futuro a maioria das aplicações serão uma combinação de banco de dados relacionais para dados estruturados, e NoSQL para dados desestruturados/variáveis, ou outros casos de uso que os RDBMS não são destinados. Todo debate colocando RDBMS vs. NoSQL é besta. Existem casos onde um é melhor do que o outro e a maioria das aplicações não-triviais são uma combinação de ambos.

Mais informações sobre o DataMapper estão disponíveis no site do projeto, assim como tutoriais e um rápido guia de como começar.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT