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!
