Arquitectura de Django framework (parte 1)

En este post no voy a referirme a detalles de instalación ni a un getting started con este producto.
Django esta construido con Python, lenguaje OO, interpretado y con tipado dinámico (+ duck typing)
En Django todo comienza creando un proyecto, este servirá de base para luego crear nuestra aplicaciones. Creamos un proyecto así:

django-admin.py startproject mi_sitio
(django-admin.py es un utilitario de comandos para tareas de administracion del django)

Esto genera una carpeta con los archivos de python que se muestran en la clase Project
(* a partir de la versión 1.4 solo esta el manage.py en la carpeta del project, y se genera una carpeta - paquete, con el mismo nombre del project, ubicandose allí los archivos settings.py y urls.py)

Como vemos, un Project posee 3 archivos python:

• Settings.py, formado por un conjunto se variables donde se setean por ej.: los detalles de conexión con la/s base de datos, directorios de archivos media y templates, aplicaciones ó módulos instalados en el proyecto.
• Urls.py, es como una tabla donde se mapean las urls de nuestro proyecto con las funciones que controlan la creación de nuestros templates html, de aquí en más views de cada aplicación.
• Manage.py, es un wrapper del django-admin.py que realiza las sig. tareas antes de delegar el comando al django-admin.py: 1) pone el paquete del proyecto en el sys.path, y 2) setea la variable DJANGO_SETTINGS_MODULE para que apunte al settings.py de su proyecto.

A continuación (desde la carpeta del project...) creamos la aplicación 'conferencias' que será parte de ese proyecto (1 ó + aplicaciones):
python manage.py startapp conferencias

Esto genera una nueva carpeta dependiente del proyecto, donde se crearán los archivos:

• models.py, aquí crearemos las clases que forman el modelo de esa aplicación, nuestros 'business objects', por ej: Conferencia, Oyente, Disertante, etc.
• views.py, aquí van los métodos que contienen la lógica de negocio que construirá la página, nuestras controladoras de Casos de uso. Cada una de estas funciones es llamada en Django : View y está mapeada a una url (no necesariamente todas...) del sitio web en el archivo urls.py del proyecto.

** Tanto projects como applications tienen un archivo python que no fue descripto anteriormente: __init__.py , este archivo es requerido por Python para tratar al directorio como un paquete, o sea un grupo de módulos (cada archivo .py).

Ejecutando el localhost para probar nuestro sitio
Django posee funcionalidad de web server para poder probar nuestras aplicaciones en un localhost, ejecutando el sig. comando desde la carpeta del proyecto:
python manage.py runserver

veremos en la consola que se validan los modelos (models.py de las aplicaciones) y luego nos muestra la versión de Django usada y que el server de desarrollo esta ejecutandose en http://127.0.0.1:8000/
Si queremos que la aplicación que se está generando se vea en otros clientes de la red podremos especificar el nro. de ip de nuestra máquina (y el puerto que deseemos) , por ej:python manage.py runserver 10.0.0.78:8000

Al probar en nuestro browser favorito veremos un mensaje de bienvenida de Django.Django es un framework web MVC, aunque ellos lo describan como MVT (model-View-Template), es un tema de conceptos que esta bien explicado por la gente de Django.

Los Frameworks son nuestro silver bullet ?

Uno nace como programador de software aprendiendo un lenguaje determinado, luego otros, siempre desarrollando algoritmos que cumplan con la funcionalidad requerida del sistema.
Como no queremos volver a escribir las mismas soluciones generamos nuestras librerías de codigo para reutilizarlo, con el diseño orientado a objetos lo hacemos todo más flexible creando clases abstractas e interfaces, usando patrones de diseño, inyectores de dependencia, etc y aplicando alguna arquitectura que nos permita convertir nuestra solución en un producto.
Así cumplimos con nuestro objetivo de vivir de esta hermosa profesión, logrando vender nuestro software a diversos clientes con distintas variantes funcionales.
Siempre uno busca ir programando menos y reutilizar más nuestros componentes y por supuesto los de otros programadores que nos ofrecen los suyos (pagos ó gratuitos), esta metodología de trabajo nos irá llevando a nuestro silver bullet, y es la motivación principal de los creadores de FrameWorks (marcos de trabajo).
Un FrameWork es una estructura conceptual y tecnológica de soporte, definida normalmente con artefactos o módulos de software concretos, con base en la cual otro proyecto de software puede ser organizado y desarrollado.

En mi experiencia como docente en la universidad, uno nota que muchos desarrolladores (generalmente colegas) de mucha experiencia, no conciben la idea del desarrollo con estas herramientas basandose en la desconfianza que genera tener que aprender algo nuevo que no sabré si el año que viene seguirá existiendo, ya que generalmente estos FrameWorks son proyectos de libre disponibilidad y open source, y su existencia depende de la buena voluntad de la comunidad que los compone y mejora dia a dia.
Si bien esta desconfianza es lógica, la proliferación de estas herramientas de desarrollo esencialmente en el ámbito web aplicando una arquitectura MVC , ampliamente consensuada y diría ya un standard para estos desarrollos, ha logrado que muchos programadores con conocimientos en diversos lenguajes de programación los utilice para lograr acercarse a su silver bullet.

Algunos buenos ejemplos de los mismos son para PHP: CodeIgniter, Symfony y CakePHP; para ASP Net: ASP Net MVC 2 , para Python: Django , para Java : JSF y Tapestry , para Ruby : RubyOnRails , etc.
Finalmente, todos los programadores que los usan no deben estar equivocados en su elección, particularmente me he convertido en un ferviente usuario de uno de ellos : Django ,luego de haber investigado las características de varios de estos frameworks.


En futuros posts iremos investigando las ventajas que nos brindan a través de mi experiencia de uso.