MagMax BlogPasos para crear un proyecto en Django
No tengo mucha experiencia en Django , así que no sería de extrañar que tuvierais mucho que enseñarme sobre este framework.
El caso es que me gustaría compartir los pasos básicos que me han parecido importantes a la hora de comenzar un nuevo proyecto.
Pasos
1.- Inicializar el proyecto
Lo primero es inicializar el proyecto. Para ello, usaremos la orden:
|
|
2.- Inicializar la aplicación
Una vez tenemos lo básico de Django, necesitamos añadir la aplicación que vamos a escribir, para ello:
|
|
3.- Habilitar ADMIN
Creo básico habilitar este módulo. Es perfectamente posible que al final lo deshabilitemos, pero me parece importante en estos momentos iniciales. Luego veremos por qué.
Estos pasos me los salto porque ya los escribí en otro artículo
4.- Crear el modelo base
Esta es la parte más compleja. Se trata de modelar la capa de persistencia. TDD no suele valer para hacer esto, así que estamos solos. Recomiendo el uso de aplicaciones como mysql-workbench .
Dado que aún no hay pruebas, no es importante que este modelo básico no sea el definitivo, pero sí es importante tener algo con lo que jugar.
En este punto entra también la sincronización de la base de datos.
5.- Registrar el modelo base en ADMIN
De nada nos sirve tener el módulo ADMIN si no lo vamos a usar :D, así que habilitamos todas las clases del modelo. No es necesario pintarlas bonitas ni retocar el estilo: basta con poder meter datos.
6.- Meter datos
Es importante tener unos datos iniciales. No es necesario que sea muy grande: basta con meter datos lo más representativos posible.
Aquí es donde entra en juego el módulo ADMIN, ya que nos ayudará a esta inserción inicial de datos.
En este punto es muy probable que volvamos a retocar el modelo base con cosas que hemos olvidado o mejoras que hemos encontrado.
7.- Exportar los datos a la fixture por defecto
Como va a ser muy normal que en los primeros pasos vayamos creando y destruyendo nuestra base de datos, será un avance que los datos que tenemos se vuelvan a meter solos. Además, los datos de prueba y los de la base de datos que podemos modificar pueden ser distintos, dependiendo de cómo hayamos configurado nuestra base de datos. En estos primeros pasos, veo crucial que estos datos sean los mismos. Ya se diferenciarán más adelante.
Para exportarlos:
|
|
Es importantísimo que el nombre sea ése. También es importantísimo que repitamos esta operación cada vez que insertemos datos a mano o que modifiquemos el modelo. Poco a poco iremos especializando las fixtures y así será más difícil que necesitemos regenerar todas las fixtures.
8.- Comenzar a meter lógica.
Ya está todo preparado. Es el momento de comenzar a meter la lógica de negocio. ¿Por dónde empezamos?
Lo lógico es probar las relaciones del modelo de las que no estamos totalmente seguros. ¿Podemos acceder a las relaciones de la manera que esperamos?
No os extrañe tener que modificar el modelo y regenerar datos. Con suerte todos los datos anteriores os valdrán. Con mala suerte, será como volver a empezar.
A medida que vamos metiendo la lógica (y no olvidéis escribir el test primero), deberíamos ir separando los datos introducidos, reduciendo el tamaño del archivo initial_data.json. Así será más difícil que un cambio en el modelo nos invalide todas las fixtures y tengamos que volver a meter todos los datos a mano. Lo normal será separarlo por modelo, y podemos hacerlo así:
|
|
Es decir: separamos el nombre de la aplicación del nombre de la clase del modelo con un punto. Esto podemos dejarlo en nuestro directorio de fixtures e importarlo en las pruebas en las que nos hagan falta, de manera que vayamos fijando las pruebas a medida que vamos avanzando. Estos pasos ya los expliqué en otro artículo.
Es importantísimo no salirnos del modelo. No queremos implementar la lógica de negocio aún.
9.- ¿Deshabilitar el módulo ADMIN?
Si ya hemos terminado el modelo, a lo mejor nos interesa deshabilitar el módulo ADMIN. Claro, que a lo mejor no… :D
Comenzar con la aplicación
Cuando ya estemos convencidos de que el modelo se comporta como esperamos, es el
momento de comenzar la aplicación propiamente dicha. Lo mejor es que, gracias al
módulo ADMIN, podemos tener un prototipo con muy poco esfuerzo, configurando la
apariencia de nuestras clases. Este prototipo será feo y poco usable (tenemos
poco más que un CRUD , _read,_update_and_delete), pero nos permitirá validar con el cliente que la capa de persistencia es válida, y lo hemos hecho en un tiempo récord, aunque es posible que sólo hagamos esto cuando el cliente sepa de la materia; como no sepa del tema, es posible que nos mire con caras raras por la usabilidad y será preferible no enseñárselo :D.
Ahora es un buen momento para comenzar con el diseño top-down, comenzando por la interfaz. De hecho, si somos varios en el equipo, esto se puede haber hecho al mismo tiempo, enseñando periódicamente esta interfaz al cliente y colaborando con la gente que hace el modelo.
En teoría la unión entre el modelo y la capa de presentación será muy sencilla, ya que sabemos que nuestro modelo funciona y será sencillo añadir nuevos casos de prueba.
Opinión
Como dije al comienzo del artículo, aún no soy un experto en Django, y estoy abierto a leer vuestras opiniones. Éstas son solo las conclusiones que yo he sacado en mi poca experiencia.
Más información
Realmente los enlaces importantes ya los he puesto entre el texto, así que tan solo los copiaré aquí de nuevo: