Arquitectura de Sistemas Informáticos

Arquitectura del Django framework (parte 1)

2010-10-26T09:27:00.005-03:00

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

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 ?

2010-10-21T11:21:00.011-03:00

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

2009-05-22T09:59:00.006-03:00

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

2009-05-19T11:54:00.010-03:00

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?

2008-06-14T15:23:00.009-03:00

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

2008-05-11T11:38:00.013-03:00

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

2008-04-27T17:25:00.008-03:00

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)

Dominios de aplicaciòn en .NET (App Domains)

2008-04-05T20:10:00.009-03:00

Todos sabemos que .NET ejecuta còdigo administrado a travès de Dominios de aplicaciòn, pero conceptualmente no son muchos los desarrolladores .Net que comprenden en profundidad esta arquitectura y sus implicancias.
Por este motivo he decidido compilar un capìtulo interesante del libro "Programming .Net Components 2nd. Ed." que trata sobre este tema.

Còdigo administrado en .NET y dominios de aplicación

Todas las aplicaciones y componentes .NET requieren de un ambiente administrado para ejecutarse. Para esto .NET utiliza un “Dominio de Aplicación” (Application Domain), que permite la ejecución de còdigo administrado de parte de los “Ensamblados” (Assemblies).
El “Dominio de Aplicación” serìa el equivalente en .NET al concepto de Proceso del S.O., con una gran diferencia: dentro de un proceso fìsico del S.O. pueden hostearse mùltiples de estos “Application Domains” . Podrìamos entonces considerarlos como “procesos lògicos” dentro de un proceso real del S.O.
( figura 1)
Esta arquitectura de “Application Domains” posee grandes ventajas con respecto a la tradicional de poseer cada aplicación(exe) y c/u de sus componentes(dlls) dentro de su propio y exclusivo proceso. Los procesos tradicionales son denominados en .NET como “còdigo no administrado”.

Algunas desventajas de esta arq. de multiples procesos son:

Crear y Destruir un proceso del S.O. consume mucho tiempo.

Mantener un proceso en ejecución es costoso en tèrminos de memoria y de los recursos que el S.O. debe ubicar en ellos.
Realizar llamadas entre procesos resulta en penalidades de tiempo, ya que cruzar los lìmites de un proceso es mucho màs costoso que realizar un llamado directo dentro del mismo. Esto es porque se necesitan mecanismos especiales para efectuar los llamados inter-proceso (por ej.: pipes, sockets, LPC/RPC) .

El còdigo en los procesos clientes se vuelve complejo para realizar llamados a otros procesos y obviamente difiere de los llamados internos.

Ventajas de los “Application Domains”:

Baja sobrecarga en el S.O. por permitir que mùltiples “procesos lògicos” se hosteen en el mismo proceso real que administra el S.O.
Los tiempos que requiere Crear o destruir un “App.Domain”, y mantenerlo en ejecución con sus recursos asignados, es una fracciòn del requerido por un proceso fìsico.
Los llamados entre “App. Domains” que estàn dentro del proceso fìsico son mucho màs ràpidos que los llamados entre diferentes procesos del S.O.
.NET mantiene un lìmite de seguridad estricto entre “App.Domains”, por lo cual los objs. del “App.Domain A” no pueden interferir con los objetos del “App.Domain B”; a menos que estos objs. decidan cooperar usando .Net Remoting.

Es importante destacar que para mantener las 2 grandes ventajas de la arq. tradicional de “mùltiples procesos”: “Aislamiento ante fallas” y “Seguridad”, cada “App.Domain” carga y mantiene su propio juego de Assemblies. En la figura 1 , la librerìa de clases llamada “Assembly 1” se carga 2 veces, una en cada App.Domain (B y C), los cuales poseen su propia copia independiente.

La plataforma .NET y los “App. Domains”
El RunTime de .Net es un juego de Windows DLLs, implementadas en còdigo no administrado con C++; estas proveen : administración del Heap, recolector de basura (GC), compilador JIT (JustInTime), Cargador y adm. de assemblies, y otras herramientas que hacen posible el “còdigo administrado”.
El “App.Domain” habilita a los Assemblies que carga, a acceder a estos servicios del RunTime .Net. Por este motivo se dice que los App.Domains son el puente que une el Mundo de còd. administrado con el Mundo de còd. no administrado.
( figura 2)
Es importante notar en la figura 2 que todos los App.Domain del mismo proceso comparten el mismo “administrador de Heap”.

Threads (Hilos) y App.Domains

Los Threads en .Net no son afines a los App.Domains, esto implica que un thread puede entrar y salir en cualquier Dominio que se ejecute en el mismo proceso subyacente. Por lo tanto nada previene que un Thread creado en un App Domain acceda a los objs. de otro App Domain en el mismo proceso.

App Domains y Remoting

.Net usa la misma arq. de llamados Remotos entre App Domains para:
· 2 App Domains en el mismo proceso
· 2 App Domains en 2 procesos distintos del S.O.
· 2 App Domains en 2 màquinas fìsicas distintas.

(figura 3)

Los clientes que estàn en el mismo App.Domain del obj. llamado pueden tener una referencia directa al obj. En cambio los clientes que estàn en diferentes App.Domains usan un Proxy para conectarse al objeto.
Un Proxy es un obj. que provee exactamente las mismas interfaces, mètodos pùblicos, propiedades y miembros que el obj. real, aunque el Proxy no puede servir al cliente debido a que el còdigo del objeto llamado y su estado residen donde el obj. estè.
Todos los proxys saben como ligarse al obj. y enviarle los llamados hechos por el cliente, esta operación es denominada “marshaling”.
El marshaling cumple con el objetivo de darle al cliente la ilusiòn de que està llamando a un objeto local y darle al servidor la ilusiòn de que està sirviendo a un cliente local. Ni cliente, ni servidor usan mecanismos remotos (pipes, RPC, sockets), debido a que estos detalles estàn encapsulados en el Proxy.
.Net requiere que si un obj. es accedido por un Proxy, la clase del obj. debe derivar de la clase abstracta “MarshallByRefObject”.

Estrategias para persistir objetos : ActiveRecord vs DataMapper

2008-02-28T09:03:00.014-02:00

Persistencia : procedimiento que es ejecutado para lograr que los datos sobrevivan a la ejecución de un determinado programa.

Porque es necesario el uso de frameworks ORM (object relational mapping) para crear una capa de persistencia que acceda a los datos de nuestra aplicación?, si esta pregunta no tiene respuesta para ti, es aconsejable que vayas aquí.

Si en .Net tengo AdoNet 2.0, que me da la posibilidad de comunicarme con la BD, permitiendome recuperar los datos y copiarlos a un DataSet local, ligarlos a mis controles en la IU, y luego persistir los cambios, via SqlCommands ó DataAdapters que realizan las operaciones CRUD de Insert,Update, Select y Delete; no puedo generar una capa de persistencia con esta tecnología?.
Por supuesto que SI, y esta fue la apuesta de la gente de Microsoft hasta la version 2.0 de NET; seguir desarrollando software donde mis entidades de negocio son directamente las filas de las tablas de una BDR (Base de datos relacional). Para esto MS ha desarrollado una artillería de controles (datagrids, combobox, listviews, etc) drag and drop con wizards que facilitan enormemente la programación ligando mis entidades de negocio con mis IU (Win y WebForms). Lamentablemente este tipo de tecnología implica comenzar cada aplicación de software como si se tratase de la 1ra que realizamos, osea : casi nula reutilización de código aunque rapidez en el desarrollo y testeo.
Esto ha permitido que miles de personas puedan estar "capacitadas?" como programadores con un curso intensivo de 3 meses; los cuales sólo podrán seguir desarrollando con las tecnologías MS del tipo "WizarDragAndDropHappyProgramming" salvo que logren ver "más allá" y comiencen a investigar como funcionan los frameworks de desarrollo (Struts de Java, RubyOnRails, CakePhp) que triunfan en la actualidad y que implican mayor conocimiento de programación y arquitecturas de software, especialmente en aplicaciones Web donde ha triunfado largamente el uso del patrón de arquitectura MVC, no es casualidad que en la nueva versión 3.5 de NET se haya desarrollado un framework que aplique esta arquitectura .

Hablabamos de reutilización, la cual es imposible sin un diseño previo que tenga en cuenta los patrones de arquitectura, donde el 3 capas lógicas es el punto por donde comenzar; donde ubicar la persistencia?, pues en la capa de acceso a datos. Ahora si lo que queremos es trabajar con "objetos de negocio" (business objects ó BOs) en las otras 2 capas superiores y no con los DataSets como "entidades de negocio" que representan a las filas de una determinada tabla, deberemos usar algún framework ORM para que haga de intermediario entre los campos de las tablas relacionadas y nuestros objetos de negocios que responden a un Modelo del dominio.

Estos objetos de negocio deben representar el mayor esfuerzo de diseño en el desarrollo de un software (la M de Modelo en un MVC), si lo que deseamos es aplicar un enfoque DDD (Domain Driven Design).
DDD propone que el aspecto más complejo en los proyectos de software no es la implementación, sino el dominio del mundo real al cual el software le da servicio. Lograr que el objetivo principal del proyecto sea el modelo del negocio y mantener un modelo de software que refleje una profunda comprensión del mismo. Esta visión fue desarrollada por Eric Evans en su libro "Domain Driven Design".
Volviendo a la persistencia, podría NO utilizar ningún fwk y codificar mi propias clases ORM?, por supuesto, aunque si desarrollas con .NET ya existen varias posibilidades open source que son excelentes, entre las cuales son de destacar NHibernate y ActiveRecord de Castle; que aplican 2 patrones de persistencia distintos que son el motivo de este post.

Active Record

Propone tener los métodos que me brindan la persistencia en el mismo objeto de negocio, y normalmente las instrucciones del mapeo atributo del objeto-campo de la tabla en la definición del objeto de negocio. Por ej. en el ActiveRecord de Castle:

De esta forma podria crear un objeto Blog y persistirlo así:

Como vemos el uso del motor de persistencia es muy natural y sencillo de usar. El único problema que se plantea es que, desde el pto. de vista de la separación de responsabilidades de las capas; en este caso; estamos acoplando los BOs de la capa de negocios con la persistencia que debería estar en la capa de acceso a datos. Porque esto no es bueno?, porque perdemos independencia y será más costoso el cambio a otra tecnología de persistencia.

Esto es debido a que son nuestros objetos de negocio los que conocen como acceder a los datos persistidos mediante, en este caso, ActiveRecord de Castle; estos métodos de manejo de persistencia no deberían ser conocidos por nuestra capa de negocios, y suele decirse que estamos ensuciando nuestro código. Si a esto le sumamos las instrucciones de mapeo (ej: [PrimaryKey]), nuestras clases que crearán los BOs dejarán de ser POCO (plain old c# objects), y estarán influenciadas por cualquier cambio en la tecnología de acceso a datos subyacente.

Por último cabe aclarar que muchos de estos ActiveRecord, como por ejemplo el DooDads (cuyo código se crea desde MyGeneration), generan el modelo de clases a partir de las tablas y relaciones de la BDR ya creada, lo cual desde mi pto. de vista no es lo correcto, debido a que un modelo de clases es mucho más rico en posibilidad de asociaciones y navegabilidad que un esquema de tablas relacionadas.

Data Mapper

Propone que nuestros objetos de negocio sean POCO (ó POJO en Java), o sea que no tengan nada de código que los acople a una tecnología dada de persistencia, ya que no es su función manejarla. Los objetos de negocio solo deben preocuparse de cumplir con el modelo del dominio vía diseño del diagrama de clases con las asociaciones pertinentes.

Este es el caso de NHibernate, que propone manejar la persistencia a través de una clase administradora de la misma: Session. Esta clase es la que se encarga de hacer las operaciones CRUD a la BDR. Por ej. para persistir nuestro objeto de tipo Salon:

Para ver un tutorial sencillo y completo sobre NHibernate ver este post de Dario Quintana.

De esta forma todo lo que tenga que ver con el DataMapper (NHibernate) puede quedar aislado en su propia capa, fuera de la capa de negocio que posee nuestros BOs. Para poder realizar esta tarea en forma más transparente es necesaria la creación de clases DAO (data access objects) que implementen los métodos más comunes que realiza la capa de persistencia.
Por ej: (DAO del Salon)

Con los DAOs de cada BO trabajarìamos con el sig. còdigo en la implementaciòn de nuestros procesos:

Por supuesto que aprovechando Generics podriamos armar un HibernateDAOAbstracto que realice todas las operaciones comunes de persistencia y de esta forma nuestros DAO especìficos de cada BO heredarìan de èste. Para màs informaciòn al respecto ver el excelente ejemplo de Billy McCafferty.

En Resúmen...

Esta visto que con NHibernate debemos codificar màs, aunque logramos mayor independencia para poder cambiar los DAOs que se implementan con NHibernate por otro que se implemente con Linq Sql por ejemplo. Tambien es importante destacar que NHibernate es un framework con muchisimas funcionalidades (manejos de transacciòn, lazy loadings, Queries tipo HQL, Criterias, interceptores, etc), esto ha hecho que en el caso del ActiveRecord de Castle, se haya implementado usando NHibernate como API base ("no reinventar la rueda", no?).

Desde el punto de vista teórico de los 2 patrones (Martin Fowler. Patterns of enterprise application architecture ), el uso de un Data Mapper nos permite manejar toda la carga y almacenamiento entre el modelo de dominio y la base de datos, logrando que ambos varien independientemente. En el Active Record se mantiene una relacion de uno a uno entre clases y tablas, siendo más dificil la implementacion de modelos de negocio complejos.

Por último, el objetivo de este post no ha sido mostrar una tecnologìa de persistencia en particular, sino revisar los 2 patrones principales que se usan para implementarla y el porque de los beneficios de usarla en un diseño que se guie por un buen diagrama de clases del modelo de dominio de la aplicaciòn a desarrollar; en definitiva promover que los programadores dejemos de lado el uso directo de los registros de las BDR y usemos objetos de negocio en nuestros desarrollos, aprovechando una arquitectura que separa las responsabilidades y posibilite mayor reusabilidad y menor mantenimiento.

Me gustaria que este post sirva para concentrar comentarios sobre el tema de persistencia, y que puedan brindar aqui sus experiencias y dudas en su uso. Nos leemos..

Fabricas (GoF) - Creando objetos sin "new" - Factory method

2008-02-12T09:03:00.000-02:00

Este patrón define una interfaz para crear un objeto, y deja a las subclases decidir cual clase instanciar.

Programar para las interfaces, NO para la implementación...

Que hay de malo en esta instrucción? : Auto a= new Sedan();

Al usar new() estamos instanciando de una clase concreta, por lo que estaremos programando contra la implementación. Es importante recordar que al acoplar nuestro código a una clase concreta, obtenemos una programación menos flexible y más frágil; o sea con más mantenimiento (y dolor de cabeza incremental) en un futuro propenso al cambio.

Ejemplifiquemos un modelo de nuestro auto:

Ante la creación de objetos de las subclases, es muy común que nuestro código se vea así:Y si tuvieramos que agregar nuevos subtipos de auto, ó eliminar otros?? --> Mayor mantenimiento y código propenso a errores !!

Identificar los aspectos que varían y separarlos de nuestro código...

Esto nos lleva a crear una nueva clase que llamaremos FabricaAutos que tendrá un método CrearAuto(int tipo) :

Con este desarrollo llegamos a un tipo de fábrica que llamaremos "Fábrica simple (simple factory), que si bien no es un patrón de diseño GoF, es una buena técnica creacional de objetos que nos acerca al siguiente patrón : Factory method

Nuestro modelo se complica...

Nuestro cliente de venta de autos (AutoShop) decide expander sus horizontes comerciales fuera de Argentina, específicamente a nuestro hermano pais de Brasil. Resulta que allí los tipos de modelos de auto difieren de los de nuestro pais; por ejemplo supongamos que los autos Rural poseen sólo 2 puertas en Brasil y 4 en Argentina, y las camionetas son doble cabina en Brasil y en Argentina no, etc, etc.
Veamos algunos cambios en nuestro código, comencemos con nuestra clase AutoShop, que ahora será abstracta:

(* protected abstract Auto CrearAuto(...))

Nuestro diagrama de clases con los AutoShops de cada pais:

Como usamos este código para entregar un Auto Sedan de nuestro AutoShop de Argentina?

Simple Factory vs Factory Method (GoF)
Simple factory decide e instancia, no tiene ninguna idea sobre que hacer con el objeto creado.

Factory method delega la creación de la instancia a las subclases, pero sabe que hacer con el objeto creado.

Estrategia (GoF) - Encapsulemos los algoritmos que varíen

2008-02-04T10:42:00.000-02:00

Definamos este útil patrón: "Define una familia de algoritmos, encapsula cada uno y los hace intercambiables. La Estrategia deja que el algoritmo varíe independientemente de los clientes que lo usen".
Su diagrama:

Vamos a nuestro ejemplo de uso, tenemos que modelar el comportamiento de un jugador de fútbol:

Luego de modelar esto, se nos pide agregar la función de atajar , obviamente no para todos los subtipos, sólo el Arquero. Nuestra solución pasaría por agregar la subclase "Arquero" y el método "Atajar()" en mi clase Futbolista.

Ahora bien, le daríamos la posibilidad de atajar a todos los subtipos de futbolistas?, pues no, por lo que deberíamos también sobreescribir el método Atajar() en los demás subtipos, poniendo algún mensaje como "función no disponible" ó retornando null.
Y que pasaría si un futbolista "MedioCentral" decide defender en algún momento como DefensorLateral y atacar como Delantero??, difícil de solucionar con nuestro primer modelo, no?.
Un poco de diseño OO...

La herencia nos trae varios problemas asociados a la extensibilidad y al mantenimiento del código de nuestro modelo.

Nuestro principio básico a recordar aquí es : Encapsular lo que varía. Identifica los aspectos de tu aplicación que puedan variar y sepáralos del resto de tu código que no cambiará; de esta forma podremos alterar ó extender aquellas partes sin afectar al resto.

Todos los patrones de diseño aplican este concepto de una u otra forma, brindando un camino que nos permita variar una parte del sistema independientemente del resto.

Volvamos a nuestro futbolista...

Separemos los comportamientos que varían, sacando los métodos : atajar, defender y atacar, de la clase Futbolista. Luego creamos un grupo de clases que representarán cada comportamiento:

En nuestra clase futbolista, definimos el comportamiento via atributos del tipo de las interfaces definidas, y métodos de seteo (ó propiedades de escritura en C#) para poder configurar el comportamiento del futbolista en cualquier momento de la ejecución.

Por último hagamos un testing, generando un futbolista con cierto comportamiento :

Con la explicación de este patrón, termino esta miniserie de GoF (Decorador y Estrategia). En próximos post veremos algunos GoF creacionales.

Desarrollar en 3 capas con .Net+NHibernate

2008-02-02T13:49:00.000-02:00

Para facilitarles la lectura de los posts referentes al desarrollo en 3 capas con .Net+NHibernate, les he realizado una versión en pdf que esta almacenada aquí (dentro de un .zip): http://www.orbitfiles.com/download/id2523464813.html

Decorador (GoF) ó agregando responsabilidades a un objeto de forma dinámica

2008-01-22T13:07:00.000-02:00

Las clases que componen la estructura del patrón decorador:

Comencemos por recordar un principio básico de diseño (abierto-cerrado): “las clases deben ser abiertas para la extensión pero cerradas para la modificación”.
Nuestro patrón GoF se basa en este principio (como tantos otros); para entender su implementación veamos una problemática para ejemplificar.

Tenemos una heladería, la cual además de vender variados gustos en distintos envases (copón, cucuruchos, vasitos), permite agregar diversos dulces al helado, por ej.: bañado de cobertura de chocolate, pasas de uva, almendras, nueces, granolas, rocklets, etc.
Por lo tanto el precio del producto variará en función de los adicionales agregados, por ej.: un cucurucho con nueces y rocklets se vende a 6$ (4$ del producto en sí + 2$ de agregados), un vasito con cobertura de chocolate se vende a 4$ (3$ del producto y 1$ la cobertura).

Nuestro diseño rígido:

Cada método Costo() necesita calcular el costo del tipo de producto y luego agregar los adic. llamando a la implementación de Costo() de la superclase.

Problemas de este diseño?

Al tener que agregar ó sacar adicionales, nos forzará a cambiar el método Costo() en la superclase y también agregar ó sacar las propiedades respectivas.

Podríamos tener que en sólo alguno de los tipos de productos como el “Copón” , se pudiera agregar un determinado adicional, como por ej.: “ensalada de frutas”.

Que pasaría si alguien quiere doble porción de “rocklets”?

Como se ve, la problemática para obtener el precio del producto, resulta interesante para diseñar, debido a las posibilidades de cambio en el algortimo que debe determinar su valor. Ante esta “posibilidad de cambio en el código” actual ó a futuro, debemos comenzar a pensar en alguna solución de diseño que nos permita la flexibilidad necesaria para incorporar los cambios sin tener que recodificar lo ya hecho, o sea con el menor impacto en nuestro código.

Apliquemos el patron para flexibilizar nuestro diseño:

Este diseño implica que cualquiera de nuestros productos concretos (copón, cucurucho,etc), puede tener 1 ó más objetos decoradores (Granola, Rocklet, etc.). De esta forma podría comprar un copón con doble ración de rocklets y nueces, ó cualquier combinación que desee, para luego solicitar su costo; el cual iría sumando los precios de los agregados hasta llegar al precio del producto concreto.

Veamos un ejemplo en código C#:

** nuestro producto Copón tiene una descrip. apropiada y un costo de 4.50$
public class Copon: Producto
{
public Copon()
{ descripcion=”Copón helado”;
precio=4.50;}

public decimal Costo()
{ return this.precio; }
}

** nuestro agregado de Rocklets hereda de Decorador
** debemos pasarle el producto a decorar en su constructor
** El costo de agregar rocklets a los helados es de 0.80$, y
** lo sumamos al costo del producto a decorar...

public class Rocklet: Decorador
{
Producto producto;

public Rocklet(Producto prod)
{ this.producto=prod;
this.precio=0.80;}

public decimal Costo()
{ return this.precio + this.producto.Costo();}
}
(** Supongamos que el adicional de nueces tiene un costo de 1$.)

Veamos como usarlo en un código cliente:

.....
Producto prod1=new Copon();
prod1=new Rocklet(prod1);
prod1=new Nuez(prod1);

** podemos agregar una nueva ración de rocklets?, claro

prod1=new Rocklet(prod1);

** mostramos el costo total del Copon con doble rocklets y nuez
System.out.println(prod1.Costo());
.....
Debería mostrar: 6.30$ (4.50+0.80+1), cabe aclarar que el método Costo() de prod1 se ejecuta recursivamente para ir capturando el precio del producto a decorar.

Arquitectura ASP Net clásica, modelo de WebForms

2007-11-30T13:39:00.000-03:00

Una aplicación web creada con Asp Net de la forma en la que nuestros amigos de Microsoft la han ideado, implica una arquitectura de 2 capas como la siguiente:

En el caso de la capa de aplicación, Asp.Net 2.0 no requiere que se ubique necesariamente código de la lógica de la aplicac. en el archivo code-behind, ya que también se puede agregar el mismo en el código de presentación (.aspx). De todas formas siempre es aconsejable mantener separado las lógicas de aplicación y presentación.

En el caso de la capa de acceso a datos, no es aconsejable acceder desde la capa de aplicación directamente a la BD ( ya sea a través del llamado a procedimientos almacenados ó vía ejecución de comandos SQL) , siempre es mejor crear clases que accedan a la tecnología usada en el acceso a datos; porque ?
Porque con esta decisión de diseño, tendremos las siguientes ventajas:

El código de acceso a datos se aísla en una clase separada, por lo cual podemos poner a trabajar a nuestros expertos en BD, mientras los analistas y programadores de lógica de aplicación trabajan en la otra capa.
Podemos afinar la perfomance de la BD (tiempos de acceso, pruebas de stress, etc) sin afectar el resto de la aplicación con nuestros cambios.
Podemos migrar de tecnología de acceso a datos, por ej.: de SqlServer a Oracle, ó a un ORM (Nhibernate ó Linq, etc); sin afectar las otras capas. (capas como módulos pluggables)

OK, me convencí, voy a generar mis clases de acceso a datos con las operaciones básicas de persistencia (CRUD: Create-Retrieve-Update-Delete), aunque tener esta flexibilidad, no posee ningún costo asociado?
SI lo posee, debido a que Asp.Net está diseñado para trabajar con los controles de las fuentes de datos embebidos en nuestras páginas .aspx, soluciones?:

No usar las fuentes de datos (DataSources) de Asp.Net, lo cual significa que no podremos usar “data-binding” en nuestras presentaciones, por lo cual debemos escribir el código que conecta la interfaz de usuario (IU) a las clases de acceso a datos.
Usar la nueva fuente de datos de objetos (ObjectDataSource) de Asp.Net 2.0, la cual está diseñada para ligar los controles Asp.Net a clases de acceso a datos, aunque esto agrega una capa de complejidad que en algunos casos tampoco soluciona el problema.

Como es una aplicación web Asp Net??

Los sitios web Asp Net son desarrollados via el uso de los Web Forms (.aspx), éstos brindan la funcionalidad web a los clientes. Un request a un recurso .aspx, como por ej.: http://miWeb.com.ar/CarritoCompras/default.aspx, resulta que sea ejecutado el archivo default.aspx (junto con su archivo code-behind) en el server, luego el resultado será una página html que se enviará al cliente.

En la siguiente imagen podemos ver una pantalla completa de ejemplo de desarrollo con la ide Visual Studio 2005, donde se aprecia una ventana con el "explorador de soluciones" (ver las extensiones .aspx de los WebForms y .aspx.cs del code behind), una ventana "toolbox" donde se ven la gran cantidad de controles Web server de AspNet que pueden agregarse al WebForm; y una página que aparece en modo de diseño, mostrando un control GridView que es usado para mostrar y editar los datos del carrito de compras.

Existen además otros archivos para el diseño de la IU como Web User controls y Master Pages, los cuales son similares a los Web Forms (están compuestos de HTML y código c# ó vb.Net en su code-behind), aunque no pueden ser accedidios de forma directa por los clientes. Estos son usados para componer el contenido de los Web Forms.
Los Web User controls (.ascx) se incluyen en los Web Forms y permiten la reutilización de código en la capa de presentación.
Los Master Pages (.master) son templates que pueden ser aplicados a gran número de Web Forms , para asegurar consistencia visual y funcionalidad a través de varias páginas del sitio. Normalmente usados para encabezado y pie de nuestro sitio, mapa del sitio, columnas con menúes.

Controles del lado del servidor, existen 2 categorías:

Html, permiten acceder a los elementos HTML de la página a través del código (en el code-behind). Se transforma un control Html (Button, TextBox, RadioButton,...) a un Html server agregandole el atributo “runat=server”. La mayoría de los controles Html están duplicados con mayor funcionalidad en los controles Web server, aunque a veces ud. deberá usarlos.
Web server, son clases .NET compiladas que, al ser ejecutadas, generan código Html como salida, eventualmente pueden incluír scripts del lado del cliente.
Pueden ser usados en los Web Forms en forma directa ó a través de la creación de Web User controls. Estos incluyen controles simples como TextBox ó Button, y otros más complejos como el GridView (el viejo DataGrid) que permite mostrar datos de la BD en forma de tabla con manejo de muchas propiedades de diseño y eventos.

A continuación les muestro algunas pantallas que fueron obtenidas del VS 2005 para ejemplificar características importantes que hacen al desarrollo de páginas Asp Net (WebForms)

El VS me permite visualizar las páginas en 2 modos: el de diseño

que me permite visualizar como se verá la página en el Browser, en el ejemplo se ve "deshabilitado" el acceso a la cabecera y pie del sitio que son parte del master page al cual pertenece esta página.

Y el modo de "código fuente":

Aquí se puede editar el código html y los controles Web de asp net que han sido agregados en modo de diseño (encapsulados en los tags ).

Por último un ejemplo del code behind (.aspx.cs) de esta página, donde normalmente generamos nuestro código de manejo de eventos de la página y de los controles :

Con este post he intentado demostrar a aquellos que no han programado con AspNet, las principales características de la arquitectura clásica de desarrollo web, así el lector podrá comprender mejor las diferencias existentes contra la nueva propuesta del MVC para AspNet posteada anteriormente.

EL futuro MVC de Asp Net

2007-11-27T10:05:00.000-03:00

Luego de haber leído los artículos de Scott Guthrie y Dino Esposito voy a realizar un resúmen de la propuesta MVC para ASP NET.

Para crear una aplicación de este tipo con VS, elegimos un nuevo proyecto de tipo “ASP.NET MVC Web Application”, de esta forma se creará una nueva solución y se añadirán dos proyectos: un proyecto web en el que implementaremos nuestra aplicación y un proyecto de testing que usaremos para escribir test unitarios (TDD...)
La estructura por defecto de un ASP.NET MVC tiene 3 directorios:

/Controllers
/Models
/Views

Por lo cual, crear las clases controladoras en el directorio /Controllers, las de modelo de datos en /Models, y las vistas en el directorio /Views.
Cabe aclarar que el Framework no te obliga a usar esta estructura, pero el template usa este patrón. Consultando a Scott sobre el uso de ensamblados (dll) para la controladora y el modelo (mis capas de negocio y acceso a datos), dijo no existir problemas en agregar las referencias a los mismos y usarlos en el MVC en vez de las carpetas creadas por default; si no fuera así no podríamos usar nuestras controladoras y modelos de un proyecto a otro, debiendo reescribir código en cada solución.

Por defecto los proyectos MVC tienen unas reglas de enrutado de urls preconfiguradas, de esta forma podemos empezar a escribir el código usando un conjunto de convenciones para nombrar las urls que van a usarse en nuestra aplicación.

Las Controladoras...

El convenio por defecto es mapear el path de la url de una petición HTTP (por ejemplo: /Products/) a una clase cuyo nombre siga el patrón UrlPathController (por ejemplo: una url que termine con /Products/ se mapeará a la clase ProductsController).
Por lo tanto si agregamos la clase “ProductsController” (que herede de System.Web.MVC.Controller) a nuestro proyecto, el framework ASP.NET MVC la usará para procesar todas las peticiones cuya url contenga la cadena “/Products”. Es decir, será llamada para procesar las urls “/Products/Categories”, “/Products/List/Beverages”, “/Products/Detail/3″ (donde 3 será el id. del producto), etc.

El framework MVC nos permite definir “métodos de acción” en nuestro controladora, y la clase base Controller invocará el método apropiado, así que cuando recibimos una petición de la forma "/Products/Categories”, la regla de enrutado tratará la parte “Categories” como el nombre de la acción, y se invocará el método Categories() para procesar la petición, si recibimos una petición a la url "/Products/Detail/5", la regla tomará el nombre “Detail” como el nombre de la acción y se invocará al método Detail(), etc.

Como accedemos a los parámetros de las urls?

La clase base Controller expone un conjunto de objetos Request y Response que podemos usar. Estos objetos tienen la misma estructura que los objetos HttpRequest/HttpResponse a los que estamos acostumbrados en ASP.NET, la diferencia es que estos objetos están basados en interfaces en lugar de en clases selladas (sealed) (MVC trae las interfaces System.Web.IHttpRequest y System.Web.IHttpResponse), esto nos da la posibilidad de poder implementarlos como queramos, uno de sus usos será crear test unitarios para clases controlador.

En la acción List , aparece un parámetro de la categoría, que es parte de la URL, y un índice de página opcional (implementaremos paginado en el servidor y usaremos ese valor para indicar qué página de categoría mostrar en la petición).
Los parámetros opcionales se manejan usando tipos de datos nullables en los métodos de acción de las controladoras. El parámetro “int?” de nuestra acción List es nullable.

Construyendo las clases del Modelo

Para crear nuestras clases que accedan a la información de la BD, Scott lo realiza mediante "Linq to Sql" (ORM), el cual me permite obtener como resultados listas de objetos. También podría usar NHibernate o cualquier otro tipo de ORM, ó Ado.Net (no recomendado, ya que debo mapear registros a listas de objetos) para construir mis clases del Modelo.

Volviendo a nuestra controladora, vemos el uso que se hace del modelo creando un objeto de tipo "NorthwindDataContext" (clase creada con la utilidad de Linq), y llamando a sus métodos, como por ej.: en el método "Detail(int id)" donde llamamos a "northwind.GetProductById(id)".

Y la Vista??
Cuando implementamos los tres métodos de acción del controlador en la clase ProductsController, usamos los parámetros de la URL para obtener los objetos adecuados de nuestra BD, para luego seleccionar una vista adecuada para generar una resputesta HTML. Usaremos uno de los métodos RenderView() de la clase base Controller para espcificar la vista que queramos usar, así como explicitamente le pasaremos los datos específicos que queremos que la vista use para renderizar la respuesta. Por ej: RenderView("Detail", product), donde product es el objeto de tipo Product obtenido del llamado al Modelo.
Para crear la vista a la cual hacemos referencia en el ej. ("Detail"), podemos usar cualquier motor de templates para ayudarnos a generar la interfaz de usuario (incluyendo motores como NVelocity, Brail - y cualquiera que escribamos ). Por defecto ASP.NET MVC usa las páginas ASP.NET (.aspx), Master Pages (.master) y UserControls (.ascx).

Conclusiones
Este framework no reemplaza el modelo basado en WebForms de Asp.Net, sólo nos agrega la posibilidad de crear nuestras aplicaciones bajo este paradigma, aplicando a la perfección este viejo patrón de arquitectura (MVC).

En el post de Dino, se le pregunta a los lectores si han escuchado hablar de REST (Representational State Transfer) , el cual es otro patrón de arquitectura que encaja perfectamente en el proceso del MVC AspNet, que describimos anteriormente.
REST define cómo los recursos de la red deberían ser definidos y direccionados con el objetivo de: obtener menores tiempos de respuesta y separar las responsab. entre front-end y back-end. Se basa en los sig. principios:

Una aplicación expresa su estado e implementa su funcionalidad actuando sobre recursos lógicos.
Cada recurso es direccionado usando una URL específica.
Todas las ventajas que poseen esos recursos direccionables se agrupan en un juego de operaciones.

Por lo tanto el framework MVC de AspNet usa un modelo REST que compite con el modelo clásico de "postback" de AspNet.

Cada página se separa en 2 componentes (controladora y vista) que operan sobre el mismo modelo de datos; esto es opuesto al clásico modelo "code-behind" donde no existen barreras que nos fuercen a separar las responsab. entre controladoras y vistas.

Aunque manteniendo las clases "code-behind" (nuestras aspx.cs) lo más ligeras que sea posible y diseñando la capa de negocios de forma apropiada (ver ejemplo de capa de negocio), un buen desarrollador logra separar estas responsabilidades manteniendo la lógica de la aplicación en la capa que corresponda.

Bueno, en este post se ha intentado aclarar un poco de que trata un framework MVC, tomándolo como una opción más a la hora de desarrollar software para Web. Cualquier extensión al tema leer los posts de Scott y Dino que están referenciados al principio.

Introducción a los frameworks MVC

2007-11-23T13:53:00.001-03:00

Ya hemos visto una arquitectura de 3 capas lógicas, ahora investiguemos como desarrollar un MVC (model-view-controller) , que fue explicado muy someramente en este post.

Sin lugar a dudas estos frameworks han ganado terreno en el desarrollo de sitios Web, donde RubyOnRails ha sido la inspiración de otros desarrolladores de frameworks de este tipo. En el caso del mundo .NET, la creación de MonoRail sumó muchos adeptos en la comunidad de desarrolladores y todos comenzamos a mirar de reojo para cuando Microsoft sumaría una propuesta de desarrollo que rompiera con el modelo basado en WebForms (.aspx), ó al menos agregara la posibilidad del MVC.

El modelo actual de MS impone que los request de los clientes son solicitudes a páginas (WebForms) aspx que contienen controles Web ASP.Net, los cuales disparan eventos a una controladora de esa página. Esta controladora es normalmente código C# ó VB.Net agregado al WebForm, y conocido como "code behind" (aspx.cs ó aspx.vb). En este tipo de arquitectura el cliente hace Request a objetos de la capa de presentación (WebForms aspx), que luego llaman a su objeto controlador para pedirle funciones, estas luego harán solicitudes sobre el Modelo (mi acceso a datos en el 3 capas lógicas).

En el caso de un MVC, el Request se realiza a un objeto de tipo Controlador que crea una presentación como Response a esa solicitud. Si se fijan en el diagrama MVC dice que la "Controladora selecciona la Vista que irá como respuesta".

Pues bien, Microsoft responde a la comunidad de desarrolladores .NET con la siguiente sorpresa (quizás no tanto...) el dia 13/11/2007 : The Asp.Net MVC framework. Ver el extenso post que publicó el gran Scott Guthrie (jefe de proyectos de MS: IIS, ASP.NET, Atlas, CLR, Compact Framework, Windows Forms, etc, etc.).
Allí se aclara que será agregado al VS 2008 como una ventaja opcional, a través de un template para la creación de proyectos de tipo MVC, también que este modelo fuerza a una limpia separación de responsabilidades de la aplicación, que permite realizar testeos de los componentes soportando TDD (desarrollo manejado por el testing), y que provee mayor control sobre las URLs que se publican en su aplicación, y mayor control sobre el código HTML que se emite desde ellas.

Esta es una vista de como las URLs se mapean a clases Controladoras:

En el post de Scott, se aclara que en la mayoría de los frameworks Web (ASP Net WebForms,PHP,JSP,...) las URLs se mapean con archivos template almacenados en el disco del servidor web, por ej: un url "/Productos.aspx" tiene un archivo subyacente Productos.aspx en disco que maneja el procesamiento de la misma.

En cambio, en los frameworks MVC las URLs se mapean directamente a clases, estas son denominadas "Controladoras" y son las que procesan los Request entrantes, manejando las entradas del usuario, sus interacciones y ejecutando la lógica apropiada para el proceso. Una clase controladora llama a una vista, la cual genera la salida HTML que se enviará como Response.
En prox. posts entraré en más detalles sobre este ASP.Net MVC y en el modelo de WebForms.

Arquitectura del software?

2007-11-20T09:39:00.000-03:00

Muchas veces nos hablan de la arquitectura en el desarrollo de sistemas. Palabrita de moda quizás...; ingenieros, analistas y programadores que se hacen llamar "Arquitectos de software" como si de un título se tratase. Hasta yo la he puesto como título en mi Blog, entonces, cual es el significado de la Arquitectura en el desarrollo de un sistema?, tratemos de averiguarlo.

En setiembre de este año se realizaron las 36 jornadas de la Jaiio en mi ciudad (Mar del Plata), y al ver el temario de los seminarios, me informo de un curso especial de 8 hs. seguidas, llamado "Introducción a la arquitectura del software", dictado por el Gerente de relac. académicas de Microsoft y profesor de la UBA Pablo Michelis. Por supuesto para entender mejor este concepto y para agregar valor a mis clases me inscribí; esto intenta ser un breve resúmen del mismo.

Comencemos por definir "Arquitectura del soft":
"Estructura de sistemas o sistema de estructuras que consisten en elementos, sus propiedades externamente visibles y la relación entre ellos"
"Propiedades externamente visibles: qué es lo que debe saber/suponer un componente sobre otro?"
Por último :
"Toda la arquitectura es diseño, pero no todo el diseño es arquitectura. La arquitectura representa las decisiones de diseño significativas que le dan forma a un sistema, donde lo significativo puede ser medido por el costo del cambio". (Grady Booch)
Creo que es la más simple y directa definición de arquitectura.

Basándonos en esta última definición podemos suponer que lo que distingue a la arquitectura de otro tipo de diseño es la significancia expresada en la dificultad ó costo del cambio.
La arquitectura del soft mantiene unidas las nociones de : diseño, estructura, estilo, racionalidad, proceso y costo.
Ahora bien, como podemos evaluar la calidad de una determinada arquitectura para nuestra solución de software? , quizás una buena arquitectura sea aquella en la que las decisiones de diseño significativas se lograron minimizar, evitando riesgos de cambio futuros. De esta forma estaríamos libres de cambiar varios aspectos del sistema sin el miedo a que tales cambios produzcan cascada de errores y cambios en el diseño que nos llevarían a altos costos de mantenimiento. Una buena arquitectura debe ser sustentable.

Como se relaciona esta visión de la arquitectura con la estructura del sistema?, pues construyamos componentes, clases, paquetes, ensamblados, etc. que sean altamente cohesivos y con bajo acoplamiento (nuestro ying y yang recuerdan?).
En una arquitectura con bajo acoplamiento, donde los puntos de variación futuras estén bien encapsulados, los efectos del cambio estarán bien aislados y el costo será relativamente bajo.
Por esto es que a nivel de arquitectura hablamos de los patrones de diseño, que nos permiten el desarrollo de mejores arquitecturas de software como por ejemplo la 3 capas explicada y ejemplificada en previos posts.

Desarrollar en 3 capas con .NET (parte 2) - La controladora y la presentación

2007-11-19T13:57:00.000-03:00

Antes de mostrar el manejo de la capa de negocio, les aclaro el concepto de Viatico:
"es una retribución diaria que cobra un empleado cuando la empresa lo envía a realizar alguna tarea fuera de su ámbito normal de trabajo (normalmente a otra ciudad), este importe diario depende de la categoría del mismo. A esto se le suman todos los gastos extras que surjan por movilidad, inscripción a cursos, etc. Normalmente se genera una Solicitud que , en caso de ser aprobada por un superior genera el Viático correspondiente." (los sustantivos marcados en negrita corresponden a algunos de los objetos de negocio de nuestro sistema).

Aclarado este punto importante para poder entender mínimamente el objetivo del sistema, a continuación veremos como desarrollar nuestra capa de negocio.

La capa de negocio (ó dominio del problema) de nuestro sistema, estará compuesta de todos los procesos que fueron analizados como casos de uso, por lo que es común denominar a estas clases : controladora del caso de uso XX.

Capa de negocio (componente ViaticoProcesos)

En mi caso de ejemplo tengo una clase CSolicitud que posee la responsabilidad de controlar todos los procesos inherentes al manejo de Solicitudes de viáticos.
Si quisiéramos darle más flexibilidad (y en consecuencia mayor reutilización futura) al sistema, deberíamos desarrollar una interfaz que agrupe los métodos comunes a todos los posibles sistemas de Viáticos (IViaticoSolicitud) .
Logrando cierta abstracción defino los contratos de mi interfaz:

public interface IViaticoSolicitud
{
void CrearSolicitud(Solicitud nueva);
Viatico AutorizarSolicitud(Solicitud s);
void ImprimirSolicitud(Solicitud s);
List BuscarSolicitud(Solicitante s);
List BuscarSolicitud(Solicitante s, DateTime Desde);
List BuscarSolicitud(Solicitante s, DateTime Desde, Boolean Aprobadas);
Solicitud BuscarSolicitud(int id);
}

Asi que entonces mi clase CSolicitud implementará mi IViaticoSolicitud:

public class CSolicitud:IViaticoSolicitud
{
// Declaro los DAOs con los que va a trabajar mi controladora
ISolicitudDao solicitudDao;
IViaticoDao viaticoDao;
IEmpleadoDao empleadoDao;
IMovilidadDao movilidadDao;

public CSolicitud()
{ // Creo la fabrica y los DAOs que usaré
NHibDAOFabrica fabricaDAO = new NHibDAOFabrica();
this.solicitudDao = fabricaDAO.GetSolicitudDao();
this.viaticoDao = fabricaDAO.GetViaticoDao();
this.empleadoDao=fabricaDAO.GetEmpleadoDao();
this.movilidadDao = fabricaDAO.GetMovilidadDao();
}

#region IViaticoSolicitud Members

public void CrearSolicitud(Solicitud nueva)
{ if (nueva.Solicitante != null)
{ try { this.solicitudDao.Save(nueva); }
catch { throw; }
}
}

public Viatico AutorizarSolicitud(Solicitud s)
{ try
{ // Marco como aprobada la Solicitud
s.Aprobada = true;
// Creo Viatico basado en la Solicitud aprobada Viatico v = new Viatico();
v.Estado = Viatico.estado_viatico.Creado;
v.Solicitud = s;
v.Numero = this.viaticoDao.DarUltimoNro()+1; // Verificar concurrencia...
// Persisto cambios en Solicitud y Grabo nuevo viatico
this.solicitudDao.SaveOrUpdate(s);
this.viaticoDao.Save(v);
return v; }
catch { throw ; }
}

public void ImprimirSolicitud(Solicitud s)
{ throw new Exception("The method or operation is not implemented."); }

public List BuscarSolicitud(Solicitante s)
{ try
{
List lista = this.solicitudDao.DarSolicitudesXSolicitante(s,null,null);
return lista;
}
catch { throw ; }
}

public List BuscarSolicitud(Solicitante s, DateTime Desde)
{
try
{ List lista = this.solicitudDao.DarSolicitudesXSolicitante(s, Desde, null);
return lista;
}
catch { throw ; }
}

// etc, etc ..............

#endregion
}

Como verán muchos de los métodos solicitan objetos a la capa de acceso a datos (clases DAO), por lo que termina siendo un llamado a un método similar en el DAO. Aquí es donde mis alumnos dicen " porqué debemos hacer las cosas por duplicado?, y si llamamos desde la capa de presentación al método del DAO directamente ? ".
OK, el tema es que la Controladora posee métodos como AutorizarSolicitud(Solicitud s), donde debemos desarrollar código que sólo es inherente al proceso de negocio y además trabajar en una transacción con varios objetos DAO.
En este ejemplo se cambia un atributo del objeto Solicitud, se crea un objeto Viatico, se pide un nro. de viático a un método estático de Viatico, y se persisten ambos objetos, vía llamado a los métodos de sus DAOs.

Capa de presentación Web (componente ViaticoWeb)

Por último, veamos un ejemplo de mi Capa de presentación Web, que permite la autorización de determinada solicitud de viático.
La página web muestra una lista de las solicitudes a autorizar por este usuario (jefe).
Selecciona una, y pulsa el botón "Autorizar".

Al pulsar este botón lo captura el evento "click" del mismo y este es el código:

protected void ButtonAutorizar_Click(object sender, EventArgs e)
{
Solicitud elegida=(Solicitud)Session["SolicitudBuscada"];
if (elegida!= null)
{
// creo controladora de Proceso de Solicitudes
CSolicitud cSolicitud = new CSolicitud();
try
{
Viatico v=cSolicitud.AutorizarSolicitud(elegida);
this.CargarGrid((Usuario)Session["Usuario"]);
this.LabelError.Text = "Viatico"+v.Numero.ToString()+" CREADO";
}
catch
{
Exception ex = new Exception();
this.LabelError.Text = ex.Message;
}
Response.Redirect("~/Admin/Autorizar.aspx");
}
else
this.LabelError.Text = "Seleccione una Solicitud para Autorizar...";
}

Como ven , se crea un objeto de tipo CSolicitud y se llama a su método AutorizarSolicitud pasándole como parámetro la solicitud seleccionada por el usuario. Cualquier error en el proceso llamado será capturado (catch), mostrándose el mensaje de error pertinente.

Capa de Objetos de negocio (componente ViaticoBO)

Mis objetos de negocio son clases independientes de la tecnología que se use para persistencia.
Ejemplo: mi BO Solicitud.

public class Solicitud
{
public Solicitud()
{ }

int id;

public int Id
{
get { return id; }
set { id = value; }
}
Solicitante solicitante;

public Solicitante Solicitante
{
get { return solicitante; }
set { solicitante = value; }
}
System.DateTime fecha_soli;

public System.DateTime Fecha_soli
{
get { return fecha_soli; }
set { fecha_soli = value; }
}
string motivo;

public string Motivo
{
get { return motivo; }
set { motivo = value; }
}

int numero;

public int Numero
{
get { return numero; }
set { numero = value; }
}
string origen;

public string Origen
{
get { return origen; }
set { origen = value; }
}
string destino;

public string Destino
{
get { return destino; }
set { destino = value; }
}
System.DateTime desde;

public System.DateTime Desde
{
get { return desde; }
set { desde = value; }
}
System.DateTime hasta;

public System.DateTime Hasta
{
get { return hasta; }
set { hasta = value; }
}
Movilidad ida;

public Movilidad Ida
{
get { return ida; }
set { ida = value; }
}
Movilidad vuelta;

public Movilidad Vuelta
{
get { return vuelta; }
set { vuelta = value; }
}

Boolean aprobada;

public Boolean Aprobada
{
get { return aprobada; }
set { aprobada = value; }
}

}

En este componente también poseo los archivos de mapeo XML que necesita NHibernate (1 por clase BO), ya que recomiendan que estén en la misma .dll que las clases que mapean.

Bueno, hasta aquí, esta breve explicación de mi desarrollo con la arquitectura 3 capas usando .NET y NHibernate; no quise profundizar en el uso de ninguna herramienta, sólo mostrar ejemplos del desarrollo a nivel de arquitectura y componentes de soft.
Quedo a las órdenes de cualquiera que desee aportar comentarios sobre mejoras, experiencias, ó preguntas sobre la forma de trabajo; que quizás no hayan quedado del todo claras en este post.

Desarrollar en 3 capas con .NET y NHibernate - Parte 1 (Acceso a datos)

2007-11-15T10:09:00.000-03:00

Luego de haber posteado que es el diseño en 3 capas, y que es un ORM con ejemplos de NHibernate, estamos en condiciones de comprender el desarrollo de software mediante esta arquitectura con el framework .NET.
Echemos un vistazo a este diagrama de componentes que aplica esta arquitectura de 3 capas (para el desarrollo de un sistema de viáticos):

Podemos ver que además de las capas de presentación, procesos del negocio y acceso a datos, tenemos los objetos de negocio aparte como si de otra capa se tratase. Aunque en la realidad debería estar en la capa del medio, esto presenta problemas en la capa de acceso a datos que pasaría a desconocer los objetos con los que debe trabajar NHibernate en nuestras clases DAO. Para comprender claramente de que estoy hablando debemos ver las clases que se encuentran en cada componente de software.

Empezando por el acceso a datos:

NHibernateCore

Aqui estan : una interfaz para los DAO (data access object) genérica (IDAO), una clase abstracta que implementa IDAO (NHibDAOAbstracto), y manejo de sesiones y transacciones de NHibernate. Su contenido responde al excelente trabajo de Billy McCafferty: NHibernate best practices with ASP.Net, cuya lectura recomiendo, antes de comenzar a desarrollar una capa de acceso a datos.

Por ej. IDAO:

public interface IDAO // maneja Generics de Net 2.0
{
T GetById(IdT id, bool shouldLock);
List GetAll();
List GetByExample(T exampleInstance, params string[] propertiesToExclude);
T GetUniqueByExample(T exampleInstance, params string[] propertiesToExclude);
List Find(string consulta);
IList FindRetLista(string consulta);
T Save(T entity);
T SaveOrUpdate(T entity);
void Delete(T entity);
void CommitChanges();
}

ViaticoDAO

Aquí se encuentran : la fábrica de DAOs, y los DAO de cada objeto de negocio.
Por ej. la clase SolicitudDAO :
public class SolicitudDAO : NHibDAOAbstracto, ISolicitudDao
// Hereda del DAO abstracto definido en NHibernateCore e implementa ISolicitudDao
// para no hacer uso directo del DAO abstracto
{

public List DarSolicitudesXSolicitante(Solicitante s, Nullable Desde, Nullable Aprobadas)
{
string criterios = "FROM Solicitud a WHERE a.Solicitante.ID = " + s.ID.ToString();

if (Desde != null)
criterios += " and Fecha_soli >=" + ((DateTime)Desde.Value).ToShortDateString();
if (Aprobadas != null)
{
if (Aprobadas == true)
criterios += " and Aprobada=1";
else
criterios += " and Aprobada=0";
}

IDaoFabrica daoFabrica = new DAOFabrica();
ISolicitudDao soliDao = daoFabrica.GetSolicitudDao();

List solicitudes;
solicitudes = soliDao.Find(criterios);
return solicitudes;
}

public Solicitud DarSolicitudXid(int id)
{
IDaoFabrica daoFabrica = new DAOFabrica();
ISolicitudDao soliDao = daoFabrica.GetSolicitudDao();

Solicitud s = soliDao.GetById(id, false);
return s;
}
}

ISolicitudDao:

public interface ISolicitudDao : IDAO
{
List DarSolicitudesXSolicitante(Solicitante s, Nullable Desde, Nullable Aprobadas);

Solicitud DarSolicitudXid(int id);
}

Por último un ejemplo de DAOFabrica:

public class DAOFabrica : IDaoFabrica
{
public IEmpleadoDao GetEmpleadoDao()
{
return new EmpleadoDAO();
}

public ICategoriaDao GetCategoriaDao()
{
return new CategoriaDAO();
}

public ISolicitudDao GetSolicitudDao()
{
return new SolicitudDAO();
}
...
}

Lo destacable en esta capa de acceso a datos es su independencia del motor de NHibernate, gracias al uso de la Fábrica de DAOs. Por ej. si quisiera reemplazar el NHibernate por Linq for Sql (del Net 3.0), cambiaría en mis DAOs la herencia de la clase abstracta que implementa los métodos contra el motor de acceso a datos:
public class SolicitudDAO : NHibDAOAbstracto, ISolicitudDao por
public class SolicitudDAO : LinqDAOAbstracto, ISolicitudDao

Por supuesto deberé desarrollar mi clase LinqDAOAbstracto para que implemente los métodos de la interfaz IDAO.

En parte 2 veremos la capa de negocio (procesos y reglas; ó controladoras de los casos de uso) y ejemplos de los objetos de negocio, cuyas clases están implementadas en su propio componente.

Que es un ORM (object-relational mapping)

2007-10-31T15:12:00.000-03:00

El ORM es un componente de software que me permite trabajar con los datos persistidos como si ellos fueran parte de una base de datos orientada a objetos (en este caso virtual). Debido a que lo standard es trabajar con BD relacionales, se deben realizar operaciones que permitan transformar un registro en objeto y viceversa. A esta funcionalidad se la llama Mapeo objeto-relacional (ORM).
Uno de los componentes ORM más utilizado (sino el más...) es el Hibernate, surgido del ambiente Java y llevado al uso del framework .NET con la versión NHibernate
Para poder explicar el porqué de la existencia de esta tecnología, nada mejor que un ppt que preparé para una clase sobre este tema a los alumnos del último año de TSSI, que les dejo disponible a continuación.

Ver ppt Upload your own

*(Si les aparece el mensaje que "ha sido removido o es privado" pulsen en "VER"
al lado del logo de "slideshare", gracias)

Sigamos solucionando nuestro diseño con los patrones

2007-09-22T19:44:00.000-03:00

Siguiendo con nuestra charla de diseño, determinemos la granularidad de los objetos intervinientes .
Los objetos varían enormemente en tamaño y número, y representan cualquier cosa desde hard a sistemas completos, por lo que como decidir que debería ser un objeto?
Veamos algunos patrones:

Fachada (GoF) describe como representar subsistemas ó procesos completos como objetos.
FlyWeight(GoF) describe como permitir un gran número de granularidad muy fina.
Abstract Factory (GoF) produce objetos cuya única resp. es crear otros objetos.
Visitor y Command (GoF) generan objetos cuya resp. es implementar una petición en otros objs. ó grupo de objs.

Especificar las interfaces de los objs.

Los patrones nos ayudan a definir interfaces identificando sus elementos clave y los tipos de datos que se envían a la interfaz. También especifican relaciones entre interfaces, ya que: requieren que algunas clases tengan interfaces parecidas ó les imponen restricciones; por ej:

Decorador y Proxy (GoF) requieren que las interfaces de sus objs. sean idénticos a los objs. deocrado y representado, respectivamente.

Especificar las implementaciones

Herencia de clases vs. herencia de interfaces, muchos de los patrones de diseño dependen de esta distinción. Por ej:

Los objs. de una cadena en Chain of Responsability (GoF) deben tener un tipo en común, pero normalmente no comparten la misma implementación.
En Composite (GoF), el componente define una interfaz común mientras que el compuesto suele definir una implementación en común.
Command, Observer, State y Strategy (GoF) suelen implementarse con clases abstractas que son interfaces puras.

En este tema, debemos tener en mente uno de los principios fundamentales del diseño OO: programar para interfaces, no para una implementación. Por que?

Ventajas de manipular objs. solamente en términos de la interfaz definida por las clases abstractas. Los clientes no tienen que conocer los tipos específicos de los objs. que usan, basta con que estos adhieran a la interfaz que esperan que esperan los clientes.
Reducción del acoplamiento entre subsistemas.
No se deben declarar variables como instancias de clases concretas, se ajustan simplemente a la interfaz definida por una clase concreta.
Para crear instancias de clases concretas usamos los patrones de creación; estos ofrecen distintos modos de asociar una interfaz con su implementación de manera transparente, y aseguran que el sistema se codifique en términos de interfaces, no de implementación.

Por último, pongamos a funcionar los mecanismos de reutilización:

Herencia vs. Composición

Son las 2 técnicas más comunes para reutilizar funcionalidad en sistemas OO.

La composición requiere que los objs. tengan en cta. las interfaces de otros, lo cual requiere interfaces cuidadosamente diseñadas, que no impidan que un obj. sea utilizado por otros. Optar por la composición ayuda a mantener cada clase encapsulada y centrada en una sola tarea. En los patrones de diseño veremos esta técnica aplicada una y otra vez...otro principio fundamental: favorecer la composición de objetos frente a la herencia de clases.

Pero qué es la composición?: método por el cual una nueva funcionalidad se obtiene mediante la creación de un objeto compuesto por otros objetos, ésta se logra delegando funcionalidad a uno de los objs. de la composición.

Mientras que la Herencia es un método por el cual la nueva funcionalidad se obtiene mediante la extensión de la implementación de un objeto existente. La superclase (generalización) captura los métodos y atributos comunes, y las subclases (especializadas) extienden la implementación con métodos y atrib. adicionales. Es más sencilla de llevar a cabo que la composición, pero...

Desventajas de la herencia:

Rompe la encapsulación, ya que expone la subclase a los detalles de implementación de su superclase
Reutilización de caja blanca, porque los detalles internos de la superclase son visibles a las subclases
Las subclases han de cambiar si la implementación de la superclase cambia

Entonces que usamos?, según Coad, solo utilizar herencia cuando:

una subclase expresa "es un tipo de" y no "es un rol desempeñado por".
una instancia de una subclase nunca necesita convertirse en un obj. de otra clase
una subclase extiende las resp. de su superclase, no las redefine ni las anula.
para una clase del problema del dominio actual, la subclase especializa un rol ó una transacción.

Por último utilicemos la Delegación cuando no existan relaciones estáticas entre clases, cuando la herencia no tenga sentido, por ej. para gestionar Roles.

Bien, como vemos obtener un buen diseño es difícil; lo primero que deberíamos saber es : que es un buen diseño?, los conceptos que detallamos antes nos ayudan a dilucidar esta pregunta. Lo segundo será aplicar los principios de diseño de forma sistemática, una buena solución es copiar a los que saben: aplicar los patrones, donde puedan aplicarse.

2007-09-08T22:43:00.000-03:00

Siguiendo con nuestra charla sobre como los patrones pueden socorrernos en nuestros difíciles momentos de diseño, veamos como "encontrar los objs. apropiados para asignarles responsabilidades".

Coincidamos en que lo más complicado del DOO es descomponer un sistema en objetos.

Para lograr este objetivo, resumamos las tareas del análisis:

Partimos de encontrar los conceptos de nuestro dominio de problema y así efectuar un modelo conceptual donde identificamos las clases que surgen del negocio (nuestros objs. de negocio) y sus asociaciones.
Luego deberíamos obtener diag. de secuencia del sistema (basados en nuestros CU) donde determinemos los eventos y operaciones del sistema
En este punto sería importante obtener los "contratos" de los CU, donde se responderá: que hacen las operaciones del sistema?. Mediante la descripción de las postcondiciones de los contratos podemos describir cómo cambia el sistema tras cada operación; esta descripción se realiza en términos de : creación y destrucc. de objetos, asociac. formadas y canceladas y modificac. de atributos.

Con toda esta documentación podremos comenzar nuestra tarea creativa más importante en el desarrollo de un sistema: el DISEÑO.

Ahora asignemos responsabilidad a nuestros objetos, aunque aclaremos que existen 2 categorías de responsabilidades: de Conocer y de Hacer.

Conocer

los datos privados encapsulados
los objetos relacionados
las cosas que puedan derivarse ó calcular

Hacer

algo el mismo: crear un obj. ó hacer un cálculo
iniciar una acción en otros objs.
controlar y coordinar actividades en otros objs.

Para asignar responsabilidad a nuestros objs. , hablemos de 3 patrones Grasp: Experto en información, Creador y Controlador. (es.wikipedia.org/wiki/Grasp)

experto en informac.: asignar la resp. a la clase que tiene la informac. necesaria para realizarla. Esto debe hacerse sin generar nuevos acoplamientos, manteniendo la cohesión alta.

creador: asignar a la clase B la resp. de crear un obj. de la clase A si se cumple que:

B agrega objs. de A
B contiene objs. de A
B registra objs. de A
B usa objs. de A cercanamente (directa)
B tiene los datos de inicialización que se pasan a un obj. A cuando es creado

Debemos agregar que muy a menudo la creación de un obj. es de alta complejidad, por lo que sería aconsejable delegar la creación a clases auxiliares llamadas "Fábricas" (factorys)

controlador: asignar la resp. de recibir ó gestionar un mensaje de evento del sistema a una clase que:

represente el sistema global ó subsistema (Fachada)
represente un escenario de CU en el que tiene lugar el evento (controladora de CU ó sesión)

Tener en cuenta que un controlador debería delegar en otros objs. el trabajo que se necesita hacer, sólo coordina y controla la actividad (compuesta de varias tareas).

Seguimos en el próximo....

Principios de diseño - Como llegamos a los Design Patterns??

2007-09-07T14:13:00.000-03:00

En una charla con mis alumnos de último año, intenté describir el proceso de pensamiento que nos lleva a la aplicación de los patrones de diseño.

Para empezar debemos recordar los conceptos básicos del diseño (no exclusivos del DOO), nuestro ying y yang : Acoplamiento y Cohesión, el 1ro. que determina el nivel de dependencia y el 2do. el nivel de unión interno (realizar una única función)

OK, teniendo en mente aquello, intentemos comprender los términos: Responsabilidad e independencia, con un diagrama UML de paquetes.

Por ej.:
Un paquete X del cual dependen muchos paquetes debe ser muy estable. No debe cambiar porque es Responsable de los 3 paquetes que dependen de él.

X es Independiente, no depende de nadie.
Su Estabilidad = Responsabilidad + Independencia

Existe alguna medida sencilla para saber que tan estable es un paquete?

Factor de Inestabilidad (I) => I=(Ce / (Ca + Ce)). Si I[0,1]=0 será totalmernte estable.

Donde : Ca (cuan responsable soy?) son clases fuera del paquete que dependen del él. Ce (cuan dependiente soy) son clases del paquete que dependen de clases externas a él.

"La estabilidad de un paquete debe ser proporcional a su nivel de Abstracción" (R.Martin-1996); esto implica que los paquetes con máxima estabilidad deben ser abstractos; y los inestables concretos.

Esto nos lleva a entender que aquellas decisiones de diseño y arquitectura de alto nivel de abstracción no suelen cambiar, así que los situaremos en paquetes estables. Aquí surge una pregunta interesante: como puede un paquete totalmente estable (I=0) ser lo suficientemente flexible como para soportar los cambios?. O sea, mejorarlo sin cambiarlo.
Respuesta, otro principio : Abierto-Cerrado. Clases que puedan ser extendidas sin modificar lo ya existente: clases abstractas.

Ahora bien, cuando intentamos seguir estos principios básicos del diseño, descubrimos que las estructuras que desarrollamos para cumplirlos, se repiten una y otra vez; esto es lo que conocemos como "Patrón de diseño". Estos deben ser soluciones probadas a los problemas de diseño más comunes, resolviéndonos los sig. puntos:

Encontrar los obj. apropiados para asignarles responsabilidad.
Determinar la granularidad (su nivel de abstracción) de los objetos.
Especificar sus interfaces.
Especificar las implementaciones que deben tener los objs. involucrados.
Poner a funcionar los mecanismos de reutilización

Ahora debemos diferenciar 2 viejas categorías de patrones de diseño: GRASP y GoF

Los GRASP no implementan las soluciones, más bien nos llevan a pensar en el diseño, a nivel de principios generales (más principios de DOO...); mientras que los GoF nos dan una solución implementable con su propio diagrama de clases que nos muestra la forma en que debemos usarlos.

En próximas notas iremos viendo los patrones relacionados con cada uno de los 5 puntos que nos resuelven los patrones (patterns).

Diseño en 3 capas? fisicas ó lógicas? es igual a patrón MVC?

2007-05-28T15:37:00.000-03:00

Diseñar en 3 capas...trata sobre no poner todo tu código en las interfaces de usuario de tu sistema (IU). Para subsanar esto, la idea es tener 3 niveles de funcionalidad bien definidos :

Capa de presentación, con nuestras IU (formularios windows, páginas HTML,..) y sus controles visuales (textBox, comboBox, dataGrids) junto con sus eventos (los click y etc.)

Capa de negocio (lógica del dominio), aqui ira todo el código que define las reglas de negocio (cálculos, validaciones). Surge de los procesos que hemos encontrado en el análisis.

Capa de acceso a datos, el código que permite acceder a las fuentes de datos. Esencialmente trata sobre 4 operaciones básicas, llamadas CRUD (por Create-Retrieve-Update y Delete), que se realizan sobre cualquier fuente de datos (normalmente alguna base de datos relacional).

Debajo de esta última se encontrará la FUENTE de DATOS que permite la persistencia de los mismos en algún medio físico.

Este diseño corresponde a las 3 capas lógicas (3 layers). No confundir con las capas físicas ó parte (3 tiers) que corresponden al lugar donde se instalan los componentes de software.

En 3 tiers la ejecución está distribuida:

Front-End, donde se ejecutan las IU del cliente. Los Browsers.

MiddleWare, recibe solicitudes de las IU a través de la red. Estos son mensajes (XML, SOAP,...) que se envían mediante protocolos de transporte (HTTP,TCP,UDP,..). El Servidor Web.

BackEnd, nuestra base de datos ó algún proceso externo a nuestro software.

Por último "Modelo-Vista-Controlador" es un patrón de diseño de arquitectura que está asociado a la idea de 3 capas (3 layers), aunque su objetivo es aún más fino. El mismo se centra en la secuencia de ejecución, desde que se produce un evento en la capa de presentación hasta que el mismo es atendido en forma completa.

Las partes que lo componen son:

Vista: componente que recibe el estímulo y genera un evento, que puede involucrar a otros objetos de la IU. Corresponde a la capa de presentación, y al Front-End(en Web:Html, JavaScript,...), aunque suele haber parte en el MiddleWare (controles ASP,PHP,...)

Modelo: componente asociado a las entidades de negocio (cliente, factura, pago,...). En 3 capas incluye parte de la capa de negocio (entidades, pero no lógica de procesos) y toda la capa de acceso a datos. En 3 tiers se instala en el BackEnd (la BD) y parte en el MiddleWare (entidades de negocio y acceso a datos).

Controlador: componente asociado a la lógica de procesos del negocio. En 3 capas la parte que faltaba y en 3 tiers en el MiddleWare.