Putting it together

by Luismi Cavallé

Me encuentro, leyendo los blogs de algunos de los ponentes de la próxima RailsConf Europe, con esta propuesta que pretende hacer más fácil la vida del desarrollador de backend en Rails.

Antes de seguir, una pequeña introducción a ActiveRecord y a las Migraciones para los que conocen menos Rails

Los principios DRY y Convención sobre configuración que han hecho famosos a este framework se hacen especialmente patentes en su implentación del patrón ActiveRecord. En Rails una clase de uno de nuestros modelos puede tener el siguiente aspecto:

class User < ActiveRecord::Base
end

Es una clase vacía que hereda de la clase Base de ActiveRecord y que solo por esto (y gracias a la “magia” de Ruby) se mapea automáticamente con una tabla de base de datos que se llame users y proporciona accessors a cada uno de los campos que contenga esta tabla. Así, podemos instanciar un objeto de la clase User según está declarada arriba y acceder a su campo name si este campo existe en la tabla users de la base de datos:

new_user = User.new
new_user.name = "pepe"
new_user.save

Por otro lado, el mecanismo de las Migraciones proporciona un sencillo DSL para escribir los scripts de creación y actualización entre distintas versiones de la estructura de la base de datos.

class CreateTables < ActiveRecord::Migration
  def self.up    
    create_table :users do |t|
      t.column :name, :string, :null => false
      t.column :email, :string
    end
  end

  def self.down
    drop_table :users
  end
end

Este script, por ejemplo, se encarga de crear la tabla users con los campos name y email. La migración incluye tanto el script para subir de versión (método self.up) como el script para bajar de versión (método self.down)

Con el objetivo de evitar al desarrollador tener que escribir las migraciones -tarea algo mecánica-, esta extensión para Ruby on Rails propone añadir la información de los campos en el propio modelo de la siguiente manera:

class User < ActiveRecord::Base
  fields do
    name :string, :null => false
    email :string
  end
end

Con esto, la simple ejecución de un script permite generar automáticamente las migraciones (y actualizar la base de datos, claro). Además parece que lo hace de manera interactiva, comparando la información de los modelos con la base de datos y preguntando al programador acerca de los casos “raros” como la eliminación o el renombrado de campos. Más info en el post original.

Otra ventaja es que esto sustituye a plugins como annotate_models (imprescindible para muchos) que añaden un comentario en la cabecera de cada archivo de nuestro modelo con el listado de los atributos de la clase para evitarnos tener que acudir constantemente a la base de datos en busca de esta información.

A mi, en principio, no me disgusta el enfoque. De hecho es muy parecido a la manera de trabajar que uso en mis desarrollos en .NET con NHibernate: Primero actualizamos la clase del modelo, luego generamos automáticamente la base de datos y, de manera “semiautomática”, las migraciones (ya volveré en algún post sobre todo esto: NHibernate, ORMs, etc…)

En todo caso, me interesa mucho la opinión de los que os dedicáis a Rails. ¿Qué os parece? ¿Es una ventaja o un sacrilegio incluir explícitamente en el modelo la información de los campos? ¿Es esto más DRY o menos DRY?…