Recuerdo perfectamente que entre las capas que más trabajo me costo entender como funcionaban y como utilizar fue la capa de negocio y es que termina siendo la ultima que descubres y la última que entiendes como usar y programar, por ello decidí dar un pequeño salto en el orden de las capas para adentrarnos en este pequeño mundito. No quiero decir que no habrá articulo sobre la capa de vista, ¡por su puesto que lo habrá!, solo quise explicar de una vez por todas, lo que mas trabajo me costo entender.
La capa de negocio puede ser manejada de varias formas y en este contexto encontramos principalmente 3 contrincantes, el patrón Transaction Script, el patrón Domain Model y el patrón Table Module.
La conclusión a la cual quiero llegar al final, no es decir cual es mejor o peor, ya que los 3 tienen sus pros y contras; la idea es dar un panorama y porque no, un par de consejos del ¿como? y el ¿cuando? utilizar uno u otro y que al final te sea mas simple tomar una decisión de que patrón(es) te conviene(n) usar mas.
Ahora, vamos a echarle un ojo a los participantes para tener un lugar en la capa de negocio.
Patrón Transaction Script
La idea básica de este patrón se basa en las rutinas.
Hace algún tiempo cuando los sistemas no eran tan complejos, si queríamos que un sistema realizará una u otra operación, se programaba una rutina. Una rutina es un conjunto de pasos secuenciales, donde las tomas de decisión son muy raras, así se tenía un proceso muy concreto para realizar algo.
El patrón TS es básicamente eso, una rutina; por ejemplo, pensemos que tenemos un sistema de ventas, donde por cada venta realizada, revisamos si necesitamos poner una orden para reabastecer nuestro inventario (si ya sé, es el ejemplo del post anterior, pero funcionará!)
Veamos el siguiente diagrama:
El foco de nuestra atención debe centrarse en la clase "PuntoDeVenta", esta es un ejemplo del patrón Transaction Script, ya que basándose en el concepto inicial, la clase "PuntoDeVenta" es la que rige toda la operación de venta.
Esto quiere decir, que si en algún momento cambia alguna regla de negocio con respecto a las ventas o si tenemos una incidencia con este modulo, sabremos donde apuntar con el dedo ¡aparte de al desarrollador claro!.
Este patrón puede ser utilizado de forma más elegante, si lo ayudamos con el patrón Command
El patrón Command (tu me llamas, yo los llamo)
El patrón Command, funciona básicamente como una interfaz (programáticamente hablando), que muestra cierto comportamiento a la capa de vista, y de alguna manera, encapsula toda la funcionalidad de la capa de negocio.
¿Qué dice que dijo?
La funcionalidad dentro de la clase "PuntoDeVenta" no esta en un solo método (por favor díganme que no), sino esta en varios métodos. A ojo de buen programador yo sacaría unos 5 métodos:
- ValidarUnidades
- RegistrarVenta
- SolicitarPedido
- ActualizarInventario
- CalcularCominsion
Expresado esto en un diagrama de clases, se vería como esto:
Es decir, la capa de presentación solo puede acceder a la lógica de negocio por medio de una interfaz, y una implementación, la implementación llama de forma ordenada los métodos definidos en la clase PuntoDeVenta, es una forma muy elegante de aislar la capa de presentación y la capa de negocio.
Pros y contras
Sin duda es una forma muy fácil y rápida de programar, cuado tenemos una lógica de negocio no muy compleja, pero... que pasa cuando la complejidad aumenta. Sin duda llegará algún otro proceso de negocio que necesite registrar algún pedido, o calcular la comisión, pero dado que es parte de otro modulo tenderemos a replicar código. Esto se puede evitar si aislamos estos métodos por medio de herencia (Nada nos restringe a usarla), aún así para que nos demos cuenta de que métodos deben estar aislados, seguramente haremos una labor de refactorización, y si el negocio es muy cambiante, bueno, tenemos un verdadero problema entre manos.
Recopilando estos datos, podemos obtener las siguientes concluciones sobre este patrón.
Pros:
- Fácil de desarrollar.
- Si el negocio no cambia fácilmente, es fácil de mantener.
- Al unirlo con el patrón Command, el manejo transaccional es muy sencillo.
- Cada uno de los procesos es fácil de probar.
Contras:
- Si el negocio cambia constantemente, significa una gran cantidad de cambios en las clases.
- Tiene una alta tendencia a replicar código.
- Cuando se hacen las refactorizaciones, se pierde más tiempo que con otro modelo.
- El impacto en los cambios, sucede como un efecto de "Domino" por lo tanto, cuando se realiza un cambio en un módulo, los módulos alrededor necesitan ser probados, aún cuando estos no tienen dependencia directa.
Si el tiempo de desarrollo es muy limitado y el negocio no esta tan complejo y susceptible a cambios, es una muy buena opción implementar este patrón.
Ahora continuaremos con los siguientes 2 concursantes
Domain Model y Table Module
No hay comentarios:
Publicar un comentario