Con el lanzamiento de nuestro primer curso de Django, Prueba Django, este mes, puede que te preguntes si Django es para ti. Django es un marco de trabajo en Python que permite poner en marcha rápidamente una aplicación web completamente funcional, y se suele comparar con Ruby on Rails, ya que ambos ofrecen una funcionalidad similar y siguen el patrón del Controlador de la Vista del Modelo (MVC). Hoy hablaré de las similitudes y diferencias entre ambos para que estés mejor informado a la hora de elegir un marco de trabajo para tu próximo proyecto.
Pitón y Rubí
Una diferencia obvia es que Ruby on Rails usa Ruby, mientras que Django usa Python. Sin embargo, usar estos frameworks no significa que tengas que conocer Ruby o Python por dentro y por fuera – conocer lo básico te permitirá crear una aplicación simple. Hay cosas específicas del framework que también tendrás que aprender que están separadas de Python o Ruby que tienen que ver con conceptos de bases de datos y de renderizado de HTML.
El patrón MVC (o MTV)
Dije antes que ambos usan un patrón de Modelo-Vista-Controlador (MVC), lo cual es cierto, pero Django nombra sus componentes de forma ligeramente diferente. Las plantillas de Django renderizan el HTML dinámicamente, así que la plantilla reemplaza a la vista en Django. Y las vistas de Django controlan realmente los datos que se muestran al usuario, así que la Vista reemplaza al Controlador en Django. Por lo tanto, en Django, Modelo-Vista-Controlador (MVC) se convierte en Modelo-Plantilla-Vista (MTV). Un poco confuso, lo admito, pero tan pronto como ves estos componentes trabajando juntos, obtienes el razonamiento detrás de este interruptor de la convención de nombres. Además, en Rails, el término «ruta» se utiliza para apuntar una URL a un controlador. Sin embargo, en Django, las URLs se llaman simplemente URLs, y el Despachador de URL se encarga de apuntar una URL a su vista correspondiente.
El ORM
Ambos tienen un ORM incorporado (o Object Relational Mapper) que permite que las consultas a la base de datos se escriban en código Python o Ruby directamente en lugar de usar sentencias SQL. El ORM se encarga de la comunicación con la base de datos. Este nivel de abstracción ayuda a escribir código, pero también facilita el cambio entre las diferentes bases de datos relacionales. Por ejemplo, si se utiliza SQLite en el desarrollo, se puede cambiar a PostgreSQL cuando se despliega con mínimas modificaciones de código.
Modelos y Migraciones
Ambas tienen también migraciones de bases de datos, que son extremadamente útiles para propagar los cambios que se hacen a los modelos en el esquema de la base de datos. Estas migraciones también actúan como un sistema de control de versiones para su base de datos. Una vieja queja sobre Django es que originalmente no tenía migraciones, pero éstas se han incluido desde hace algunos años desde Django 1.7. Personalmente prefiero la forma de Django de organizar los modelos y las migraciones de bases de datos. En Django, cuando quieres cambiar una tabla, (1) cambias el archivo del modelo (models.py) directamente, y (2) inicias los comandos de migración makemigrations y migrate. Luego, se cambia la tabla correspondiente en la base de datos. Y entonces puedes encontrar tus definiciones y campos del modelo en un solo lugar: el archivo models.py.
MIGRACIÓN DE BASE DE DATOS EN DJANGO
Por ejemplo, aquí hay una migración de la base de datos en Django:
Entonces, si quieres añadir un nuevo campo llamado imagen, sólo tienes que editar models.py:
Y volver a ejecutar las migraciones:
En Rails, en cambio, no se cambia el archivo modelo, sino que se genera un archivo de migración desde la línea de comandos para cada cambio que se quiera hacer. Puedes ver el esquema de tu base de datos en schema.rb, pero no hay una lista de campos del modelo que puedas editar directamente como en Django.
MIGRACIÓN DE BASE DE DATOS EN FERROCARRILES
Originalmente creando los modelos:
Quiere añadir un nuevo campo de imagen:
Arriba hay un poco de la magia de la convención de Rails. Si el nombre de la migración es de la forma AddXXXToYYY y va seguido de una lista de nombres y tipos de columna, entonces se creará una migración que contenga las declaraciones add_column y remove_column apropiadas.
Obsérvese también que en el caso de Django, los validadores como max_length y required y cualquier relación se establecen convenientemente en models.py. Pero para Rails, los validadores y las relaciones deben ser añadidos al archivo .rb del modelo. Aquí, se generaría soup.rb y podríamos añadir validadores como sigue.
Convención vs. Configuración, o «Magia» sobre el control
Rails enfatiza la convención sobre la configuración, donde muchas cosas «mágicamente» te suceden con sólo seguir ciertas convenciones de nombres. Django, por otro lado, proporciona más flexibilidad al confiar en la configuración. Por ejemplo, en Rails, para crear una ruta que muestre una cierta sopa por id, podemos usar verbos HTTP como los siguientes en routes.rb:
O si has seguido las convenciones de nombres de Rails al nombrar los métodos de tu controlador, este comando asignará automáticamente las siguientes rutas en routes.rb:
En Django, sin embargo, las expresiones regulares coinciden con las URL y las asignan a los controladores. Como Django no se basa en convenciones, no tiene un ayudante como el recurso de Rails, pero tiene flexibilidad en la configuración.
La Administración
Otra gran característica incorporada que ofrece Django es la interfaz de administración que permite ver y cambiar las tablas de la base de datos. Para obtener esta funcionalidad en Rails, necesitas instalar una biblioteca externa de tu elección.
Proyecto y estructura de aplicación
Por último, pero no menos importante, me gusta mucho la estructura del proyecto de Django. En Django, tienes un proyecto exterior con aplicaciones separadas en el interior. Cada aplicación es responsable de un comportamiento específico, por ejemplo, podrías tener aplicaciones separadas para el .com principal, el blog y la tienda. Las aplicaciones tienen sus propios modelos, plantillas y vistas, pero también se pueden conectar a cada una de ellas. También pueden compartir la configuración utilizando el proyecto externo. Este formato te da una estructura más limpia cuando tienes un proyecto grande.
Conclusión
En general, ambos marcos agilizan el proceso de hacer aplicaciones web modernas, y la gente es fan de cada uno de ellos por diferentes razones. Personalmente me encanta Python, así que es una elección fácil para mí. Ahora que has visto las similitudes y diferencias, puedes tomar la decisión por ti mismo, y puedes ver que si le dedicas un poco de tiempo, no es muy difícil hacer el salto de un marco a otro. Comprueba ahora mismo lo que es Django jugando en nuestro nuevo campo de Django, Prueba Django, ¡y mira si encaja bien en tus propios proyectos!