José F. Romaniello

Las aventuras y desventuras de un codificador.

Esta es una idea de arquitectura que me gusta. Algunas cosas que yo considero no existen antes de empezar:

  • Soluciones mágicas ni herramientas que lo hacen todo. Olvidate de construir una aplicación empresarial con esto o algo como esto.
  • Una arquitectura que funcione bien para todos los casos.
  • Una herramienta que sea una bala de plata para resolver cualquier problema.
Sin embargo, es posible:
  • Construir aplicaciones a partir de modelos probados
  • Construir software sencillo, escalable y mantenible.
  • Crear software de calidad.
  • Disminuir fricciones que existen en el desarrollo de software.
  • Hacer las cosas bien.
La arquitectura básica que voy a explicar, es la siguiente: Modelo El modelo es lo que hace a la aplicación ser lo que es. Como ejemplo he agregado dos componentes; entidades y servicios. Entidades Las entidades representan las clases de objetos que intervienen en el dominio de nuestro problema. Describen de cierta manera el lenguaje que utilizara nuestra aplicación. Entonces, si en nuestra aplicación intervienen caballos, seguramente tendremos como entidad una clase caballo, lo mismo con facturas, etc. La mayoría de las veces hablamos de objetos con significado en el mundo real artículos, comprobantes de compra, etc. Dichas entidades usualmente tienen varias propiedades como por ejemplo Código, Descripción, Cantidad, Precio, etc. Las propiedades pueden ser de diferentes tipos:
  • Tipos básicos del lenguaje de programación, ej: int, string, float, etc.
  • Entidades; ej: la clase factura podría tener una propiedad Cliente que a su vez es del tipo Cliente.
  • Colecciones de entidades; ej: la clase factura podría tener una propiedad Lineas, que es una colección genérica, tipo IList .
Además de propiedades poseen métodos que implementan lógica de negocio. Un método de la clase Factura, podría ser CalcularNeto. Lo que es importante mencionar en este punto, es que bajo ningún punto de vista tenemos que pensar una entidad como una tabla o un registro de la base de datos, simplemente es algo mas complejo pero mas aproximado a la realidad. Por otro lado, es preciso que las entidades sean POCO o POJO, es decir, clases simples que no implementen interfaces complejas ni estén fuertemente ligadas a un framework en particular. De esta manera son fáciles de mantener, usar y entender. Con lo cual "YO" descartaría completamente la idea de Datasets Tipados y hasta en cierto punto a la propia nueva herramienta de Microsoft, Entity Framework. (Ya lo se, tienen un bonito editor y buen soporte técnico.) Servicios Los servicios son objetos que llevan a cabo cierta funcionalidad del sistema. En estos casos la funcionalidad que implementan es demasiado compleja y en algunos casos depende de componentes externos a nuestro sistema, por lo cual resulta inapropiado embeberla en las entidades. Un ejemplo de servicio, podría ser ValidadorDeOrdenesCompra. Interfaz La interfaz de usuario le permite al usuario interactuar con el dominio de la aplicación. El patrón MVC es muy recomendable en sistemas de nivel empresarial. Básicamente, tenemos 3 componentes interactuando entre si:
  • Modelo: es lo que se explico previamente, intervienen entidades y servicios.
  • Vista: Se encarga solamente de mostrar y capturar los datos de la interfaz gráfica.
  • Controlador: Es quien manejar el flujo de la interfaz de usuario, por ejemplo: toma datos del Modelo y se los asigna a la Vista, toma los datos que la Vista capturo y llama a métodos del Modelo para persistir los datos.
Repositorios En este nivel nos encontramos con funcionalidad para almacenar y recuperar las Entidades del dominio. A simple vista se podría pensar directamente en una base de datos (DAO), pero también existen otras clases de repositorios y me permití mencionar un repositorio que obtenga Entidades de mi dominio desde un webservice. DAO Un DAO, Data Access Object, posee la funcionalidad necesaria para guardar y recuperar las Entidades en una base de datos. En el objeto DAO se encapsula la funcionalidad para interactuar con la base de datos. Cada DAO, se encargará de solo una entidad, pero es posible que existan entidades sin su correspondiente DAO (simplemente no necesitan ser almacenadas). Así, la interfaz de una clase dao para una entidad Factura podría contener los siguientes métodos:
  • ObtenerPorNumero(NroFactura) as Factura
  • ObtenerTodos() as IList
  • ObtenerPorMes(Mes) as IList
  • Guardar(Factura)
  • Eliminar(Factura)
Lo que es importante destacar es que hasta esta clase llega todo lo relacionado a la base de datos. Es bastante inapropiado tener instrucciones SQL o referencias a objetos ADO.Net fuera de aquí. En otro momento voy a escribir un post dedicado exclusivamente a objetos DAO y como simplificar esto mediante ORM. Para terminar En proximos post voy a detallar en mayor medida cada uno de los componentes de esta arquitectura. Por otra parte, quisiera dejar algunas referencias: Parte de esta arquitectura esta basada en este artículo: NHibernate Best Practices with ASP.NET, 1.2nd Ed. Ayende Rahien: http://ayende.com/ Jeffrey Palermo: http://jeffreypalermo.com/ Deja tu comentario, saludos!

| More

2 comentarios:

Muy bueno el post, espero que continues y detalles todo lo que prometes, porque estamos empezando a hacer un sistema en capas .NET y lo vamos a necesitar. Saludos.

Gracias Nestor.
Muy pronto habra nuevo material.

Publicar un comentario en la entrada