Alfredo Juarez

Simon brown ha publicado un articulo con el que estoy muy de acuerdo; se trata del por qué es bueno documentar la arquitectura del software, ya que los comentarios en el código fuente no nos ayudan a entender del todo como funciona el sistema.

Una lectura ampliamente recomendable.

Link: Coding The Architecture

97 things es un proyecto que busca reunir 97 cosas que un arquitecto debe saber.

La idea de esta lista es reunir experiencias publicadas por diferentes arquitectos, si logras hacer que publiquen un contenido tuyo te conviertes en autor. Al final O’reilly publicará un libro con los 97 axiomas que un arquitecto debe conocer.

Hasta el momento llevan 82 y siguen subiendo.

(Via)

La mayoría de aplicaciones requieren de interacción con una base de datos, ya sea del tipo relacional u orientada a objetos y en la mayoría de los casos la persistencia de datos está mezclada con la lógica del negocio. Lo que supone un problema a la hora de querer cambiar el motor de base de datos.

Para entenderlo mejor formularemos un ejemplo de la vida real.

Imaginemos que estamos desarrollando una aplicación en la empresa donde trabajamos y estamos utilizando MySQL como motor de base de datos. Estamos en la fase de pruebas (ya a punto de publicar el producto final), y por alguna extraña razón a tu jefe se le ocurre que mejor deberíamos usar Oracle, por que se lo recomendaron, piensa que es mejor, etc.

Que pasa si tenemos todo mezclado (lógica del negocio, métodos de acceso a datos, etc), se convierte en una tremenda pesadilla.

Para nuestra suerte existe el patrón de diseño Data Access Object (DAO), que se encarga de encapsular la interacción de una aplicación con la base de datos.

¿Como funciona?

DAO encapsula el acceso a la base de datos, de esta manera cuando la capa de lógica de negocio necesite interactuar con la base de datos, ésta utilizará los métodos ofrecidos por DAO. Generalmente la clase de operaciones que ofrece la capa de datos se le conoce como CRUD (Create, Read, Update y Delete).

Cuando la capa de negocios necesite almacenar datos (por ejemplo) solo tendrá que hacer referencia al método correspondiente para insertar los datos de la clase DAO, de esta manera si en algún momento se llegara a optar por usar otro motor de búsquedas, la capa del negocio no se debe preocupar ya que sólo bastará con actualizar la capa de datos. Si hablamos de patrones algunos detectarán por aquí que se están delegando responsabilidades, una buena práctica de la orientación a objetos.

De hecho el método de persistencia no debe de interesarle a la capa de negocios, es decir, a él no le importa si los datos se guardan en una tabla MySQL, XML, Texto plano o se imprime, de esto se encarga DAO.

Por cada tabla de una base de datos relacional existirá un DAO. Esto consiste básicamente en una clase que es la que interactúa con la base de datos. Los métodos de esta clase dependen de la aplicación y de lo que queramos hacer. Pero generalmente se implementan las 4 funciones básicas (también conocidas como métodos CRUD).

Una vez entendido el funcionamiento de DAO, es conveniente explicar un nuevo término que nos será de ayuda para completar la implementación de nuestra capa de persistencia. Se trata de los DTO’s (Data Transfer IObject), los cuáles son utilizados por DAO para transportar los datos desde la base de datos hasta la capa de lógica de negocio o vice versa.

En pocas palabras un DTO es un objeto que en su interior tiene como atributos los mismos atributos del modelo, con sus correspondientes accessors (Setters y Getters).

Diagrama DAO

Ahora veamos un ejemplo

Tenemos una aplicación que entre una de sus tantas funciones es controlar los datos de clientes, y queremos usar DAO para el manejo de la persistencia de dicha aplicación.
Primero que nada de define el modelo 8en este caso de clientes), para después partir con la codificación de los respectivos DTO y DAO.

DTO

Class ClientesDTO
{
      private $id;
      prívate $nombre;
      prívate $direccion;

      public static function getID( )
      {
          return $this->id;
      }

      public static function getName( )
      {
          return $this->nombre;
      }

      public static function getAddress( )
      {
          return $this->direccion;
      }

      /* Setters */
      Public static function setID( $id )
      {
          $this->id = $id;
      }
      Public static function setName( $name )
      {
          $this->nombre = $name;
      }
      Public static function setAddress( $address )
      {
          $this->direccion = $address;
      }
}

DAO

class clientesDAO
{
     public static function create( $dto )
     {
          /* implementación para la creación de un nuevo registro */
     }

      /* aqui van los demás metodos CRUD */
}

Por obvias razones no escribí todo el código necesario ya que este artículo es meramente informativo, pero pienso que es explicito el ejemplo para comprender el uso del patrón DAO.
En la próxima entrega les mostraré un ejemplo más real, utilizando una mezcla de patrones, como el DAO, Singleton, Factory y Façade.

Es un modelo de arquitectura de software, algo similar al modelo-vista-controlador (MVC). PAC se utiliza como una estructura jerárquica de los agentes, cada uno de ellos consistente en una tríada de presentación, la abstracción y el control de partes. Los agentes (o tríadas) se comunican entre sí sólo a través del control de parte de cada tríada. También difiere de MVC en que dentro de cada tríada, se aísla por completo la presentación (vista en MVC) y la abstracción (modelo en MVC), Este ofrece separar el modelo y la vista, lo cuál, da al usuario una experiencia de usuario por los cortos periodos, de cómo la interfaz (presentación) puede ser mostrada antes que la abstracción este completamente inicializada.

El control es algo similar al Controlador en la arquitectura MVC. Este procesa eventos externos y actualiza el modelo. También se actualiza directamente la parte de presentación. Sin embargo, es diferente del controlador en MVC en la medida en que éste pasa los cambios que se están realizando a su componente padre.

La Abstracción contiene los datos, al igual que en MVC. Sin embargo, puede ser sólo una parte de la estructura de datos completa de la aplicación, y no desempeñar un papel activo en la notificación de cambios.

La presentación es exactamente igual que la vista en el MVC. Muestra la información desde la abstracción.

Como funciona

El control padre crea los elementos de su hijo PAC, ya sea en el arranque del programa, o dinámicamente en tiempo de ejecución.
Cuando el control de un PAC recibe un evento de usuario (1), este debe actualizar su presentación (2a) y/o su abstracción (2b). A continuación, se envía un evento de cambio a su padre (3). El padre actualiza sus hijos (pero no al nodo donde surgió el cambio) (5), por lo que todos actualizan su Presentación (6a) y/o abstracción (6b). Después que los nodos han sido actualizados, el padre se actualiza (7). Esto termina cuando todos los elementos PAC necesarios han sido actualizados.

Los hijos y padres pueden enviar eventos muy concretos para actualizar a sus vecinos. De esta forma, los elementos PAC podrán decidir la extensión del efecto del cambio. Pequeños cambios no tienen por qué ser propagados a través de toda la jerarquía.

Problemas

Las actuales herramientas de programación visual tienen algo relacionado con esta arquitectura, pero tienen todo tipo de peculiaridades y excepciones. Así que se puede tratar de reconocer la arquitectura en herramientas visuales, pero no son tan exactos. Además, la mayoría de herramientas dicen basarse en la arquitectura MVC, lo que tampoco es completamente cierto.

Técnicas de implementación

El Control es modelado por el patrón de diseño Mediator.
La presentación es modelada por el patrón de diseño Strategy.

Start Slide Show with PicLens Lite

Hacia una definición de la arquitectura

La arquitectura ayuda a completar los requisitos