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.

Como soluciona Asp.Net el "stateLess" de la web

En un curso que dicto sobre AspNet, una pregunta recurrente es "como maneja el lenguaje la falta de estado en el entorno web?".

Digamos que en un programa Windows local, el usuario interactúa con una aplicación que está ejecutandose ininterrumpidamente, la cual almacena su información en una porción de la memoria del computador. En una aplicación Web esto no es así, si bien un sitio desarrollado con ASP NET pueda verse como “ejecución ininterrumpida”, esto es solo una ilusión.

En un típico Web Request, el cliente se conecta al Web Server y solicita una página, cuando ésta es enviada la conexión se cierra y el Web Server abandona cualquier información que posea del cliente. Por lo cual cuando el cliente recibe la página solicitada, la aplicación ya ha parado su ejecución. Por este motivo Asp Net nos dota con las siguientes posibilidades para manejar el almacenamiento de los datos (mantener el estado):

Tenemos 4 posibilidades, aquí las 2 primeras, ViewState y QuieryString

Por último, cookies y session state:

AOP y DI con Spring Net

Finalmente y despues de tantos meses, he vuelto al ruedo con mi Blog, y he visto que me he comprometido en mi anterior post a proveer de un ejemplo de AOP con Spring Net, en este link tienen un ejemplo sencillo, donde se implementa un "Around Advice", lo cual implica poder ejecutar código antes y despues del llamado al método actual interceptado.

Tambien les dejo un ejemplo de como realizar DI (dependency injection) :



por ejemplo, tenemos una clase "User" que tiene un servicio "UserService", que a su vez tiene en su constructor un parametro que permitirá setear (inyectar...) el DAO con el que trabajará. (si.., tambien podriamos haberlo hecho en una propiedad)



Luego, definimos en un archivo xml de config. (app.config o web.config) , donde se define un objeto "userService" con un parámetro para su constructor ("dao") , que será otro objeto llamado "userDao".

A continuación se muestra la definición del object id "userDao", que como ven es de tipo SpringApp.Data.NHibernate, efectivamente Spring no reinventa la rueda y usa como ORM a NHibernate.

Este objeto llamado "userDao" tiene una property llamada "SessionFactory", que es la definida dentro de la config. de NHibernate dentro del mismo xml.

Por último para crear un objeto "userService" con el seteo hecho en el archivo xml (mi DI):

En la 1er. linea debo cargar el contexto de lo definido con Spring (IApplicationContext) y luego le pido a ese contexto que me dé un objeto cuyo id es "userService".

AOP - Que es la prog. orientada a aspectos?

Orientar la programaciòn al uso de "aspectos", que extraño suena no?; tratemos de explicar su uso en la POO.

Definiciòn de AOP

Segùn Wikipedia : "intenta ayudar a los programadores en la separaciòn de incumbencias (soc-separation of concerns), especificamente las incumbencias cruzadas (cross-cutting concerns), como un avance en el uso de la modularizaciòn."

En la POO la modularizaciòn implica el uso del encapsulamiento, ya sea a nivel de clases, paquetes, componentes, capas. Siempre buscamos asignar responsabilidades y aislarlas en su propio mòdulo funcional, logrando diseños de caja negra que nos permitan reusabilidad y fàcil mantenimiento.

Aunque, existen ciertas incumbencias ò àreas de interès (concerns) que son generales a varios mòdulos, por lo que, al incluìr esta funcionalidad en ellos, estarìamos repitiendo còdigo; el cual en caso de tener que modificarlo implicarìa hacerlo en todos los mòdulos que lo contengan. Por ejemplo: la seguridad, el "logging", el "debugging", sincronizaciòn y administraciòn de transacciones, cacheo.

Entonces existen caracterìsticas como las mencionadas que no son modularizables, son incumbencias que no pueden ser aisladas dentro de un solo mòdulo, ya que es su naturaleza estar distribuida su implementaciòn en varios mòdulos.






En este punto debe quedar claro que nuestro sistema està formado por un cojunto de "concerns", donde algunos de ellos no pueden formar parte de un solo mòdulo, a estos los llamaremos "cross-cutting concerns".

EL AOP esta diseñado para manejar estos "cross-cutting concerns", proveyèndonos de un mecanismo conocido como "Aspecto" (aspect).


Aspecto

"Modularizaciòn de un "concern", sin el cual deberìa implementarse a travès de mùltiples objetos con distintas responsabilidades."

"Funcionalidad que se quiere aplicar a otras partes del còdigo (autorizaciones, logging, transacciones,...)"


Como implemento AOP en .NET?

Hay varios frameworks que permiten trabajar con AOP en .NET, entre ellos es de destacar Spring.NET que nos da esta funcionalidad con el uso de su componente Spring.AOP

Para comprender el funcionamiento de los Aspectos, debemos definir algunos conceptos AOP:

Advice : cada una de las cosas que puede hacer un Aspect

Join Point: Punto del programa en el que se ejecutarà un Advice

Point Cut: Conjunto de Join Points, un conj. de mètodos donde se ejecutarà un Aspect.

Target: El objeto sobre el que se aplicarà el/los aspecto/s. Es el obj. que contiene el Join Point.

Introduction: Manipular un Target para añadirle còdigo. Permite introducir nuevas interfaces a cualquier "obj. advised" (Target). Por ej.: un obj. puede implementar "IAuditable" para simplificar el rastreo de cambios en su estado.

Weaver: Caract. de ensamblado para crear los "objs. advised". Puede ser hecho en tiempo de ejecuciòn (como Spring.Net) ò en tiempo de compilaciòn (usando el compilador Gripper-Loom-Net)

Algunos tipos de Advice:

• Before : Justo antes de un Join Point
• After: Despuès de terminar un Join Point (haya o no excepciòn)
• Around: envuelve la ejecuciòn del Join Point, pudiendo ejecutar còd. antes y despues, incluso evitar su ejecuciòn.

En un pròximo post entrare en detalle sobre el uso de AOP de Spring con un ejemplo concreto.

Desarrollando Software con un Modelo de Negocio

Aquí les dejo la presentación que dicté en la UTN Mar del Plata, en el marco de las "Jornadas sobre Desarrollo Software" (Mayo/08).
La temática gira alrededor de los siguientes conceptos: Componentes software, Modelo de negocio (Trans.Script y Domain Model) , Persistencia de objetos de neg. y acceso a datos con NHib. (DataMapper y ActiveRecord), DAO.

Cualquier problema con la visualización de la presentación pulsar en opción "View" de Slideshare.

View Upload your own

La aplicación Web que demuestra estas tecnologías ( desarrollada con AspNet 2 y NHib.), se encuentra aquí : ConferenciaWeb.
Dentro del zip tienen una carpeta con las instrucciones para instalar y ejecutar; tener en cuenta que necesitan el VS 2005 y en lo posible SqlServer 2005, si necesitan probar con otra BD deben cambiar los drivers del NHibernate en el web.Config. Espero les sea de utilidad.

Por ultimo les dejo el enlace a la filmaciòn del seminario que realizò la gente de TecnoTV de Canal 10 de MdP : seminario de capas con NET

Jornadas sobre Desarrollo de Software (MdP) - MAYO/08

Los dias sabados 10,24 y 31 de Mayo de 10 a 13.30 hs, se dictaràn 3 seminarios orientados a desarrolladores de software : .NET+NHibernate, RubyOnRails y Java con EJB-Struts (reprog. del dia 17/5) respectivamente.

Estas jornadas se haràn en el aula Magna del Centro de Estudios Mar del Plata de la UTN.
Para ampliar sobre las mismas ver la entrevista que me efectuaron en el programa Mercados & Empresas de Canal 10 del cable de MdP.

Cualquier interesado de la zona (estudiante o profesional) con conocimientos en POO puede inscribirse gratuitamente en el sitio de la UTN: http://www.mdp.utn.edu.ar/ (ver folleto)