Capa de Negocio (Parte 3): Table Module

Patrón Table Module

Es último patrón y no por eso el menos importante.

Este patrón tiene su base en el modelo E-R de una base de datos, ya que ahora las clases contendías en la capa de negocio son una representación de las tablas de la base de datos.

Es decir que ahora habrá una Clase que se encargará de administrar todo el comportamiento y lo datos que una tabla en particular.

La diferencia principal entre el Domain Model y el Table Module es que, mientras que con el patrón Domain Model manejas un objeto por cada Cuenta Bancaria (retomando el ejemplo anterior) con Table Module, tendrás un solo objeto para manejar todas las Cuentas Bancarias y ahora si tendrás una clase llamada "OperacionBancaria".

Este Patrón hace uso de la fortaleza que tienen las bases de datos relacionales, como los índices de las tablas mediante los cuales podemos obtener información particular de una forma mas rápida.

Retomemos el ejemplo de la base de datos anterior.

Así un diagrama de clases para este patrón, luciría muy semejante, por no decir igual.

Las llaves primarias de una tabla es un índice natural de la tabla, por tanto podemos explotarlo y preguntar por una cuenta Bancaria por un "Id" especifico, lo cual nos sugeriría tener un método para dicho fin, algo semejante a lo siguiente:

cuentaBancaria.getCuentaBancariaById(long idCuentaBancaria)

El patrón puede aplicarse por medio de una instancia de clase o bien una serie de métodos estáticos, y eso es gracias a que la clase original no guarda comportamiento especifico para cada una de las cuentas bancarias por el contrario, debe mantenerse lo mas neutral posible.

Cada clase podría incluir una fábrica de sentencias SQL o delegar esto a la capa de datos por medio de un patrón Table Data Gateway (prometo que pronto habrá un articulo hablando de este patrón), lo cual simplificaría aún mas las cosas y permitiría manejar de una forma mas natural las operaciones sobre la tabla en cuestión.

Algunas veces llego a pensar que este patrón es una mezcla entre el Domain Model y el Transacction Script, si utilizamos un patrón Command, ya que ahora cada clase podría definirse como una clase de dominio y un proceso esta conformado a menudo por varias clases para conformar una transacción, si le aplicábamos un patrón Commnad, el manejo transaccional es relativamente sencillo.

Pros y Contras

Al igual que los patrones anteriores tiene algunas cosas buenas y otras que no lo son tanto.

Pros:

• Dado que esta basado en la estructura de un E-R, hace que la propia tabla este estrechamente ligada a la capa de negocio lo cual hace que las operaciones con la tabla sean fácilmente programables y comprobables.
• Cada Clase aísla las operaciones sobre una tabla, por tal motivo si la base de datos tiende a cambiar, es muy fácil soportar este cambio.
• Cuando un cambio en la base de datos surge por la necesidad de mostrar algún dato extra en la vista, los cambios en el diseño de la aplicación son prácticamente nulos.
• El desarrollo es sumamente sencillo, y el tiempo también baja considerablemente al tener perfectamente definida la estructura E-R del la base de datos.

Contras:

• Al igual que Transaction Script, este patrón funciona muy bien con una lógica de negocio sencilla, si la lógica es compleja, se comenzará a genera una maraña de dependencias entre las Clases de negocio.
• Dado que cada Clase tiene comunicación estricta con una tabla, si un proceso tiene que actuar sobre muchas tablas, podría verse reflejado esto en una baja de performance de la aplicación, aunque algunos tips sobre la capa de datos podrían ayudar (en el siguiente articulo veremos algunos).
• Aplicar polimorfismo es algo complejo, ya que a final de cuentas se esta haciendo un mapeo de cada tabla, y las bases de datos relacionales carecen de habilidad polimórfica.

En conclusión

El patrón Table Model también facilita mucho el proceso de desarrollo y aunque puede cargar una lógica de negocio ciertamente compleja, entre mas compleja se vuelva esta, estaremos las cerca de comenzar a generar un código "espagueti", es decir, una maraña de dependencias y llamadas entre clases.


Pongamos todo sobre la mesa (Transaction Script, Domain Model y Table Module)

Los 3 patrones de diseño son buenos bajo ciertas circunstancias y no son necesariamente excluyentes, incluso hay casos de éxito donde se han combinado un par de patrones, aunque si es necesario manejar una documentación apropiada para saber donde se aplico un patrón y donde el otro, yo personalmente he aplicado 2 patrones simultáneamente y me ha funcionado.

El patrón Transaction Script lo utilizo principalmente para procesos sin gran trascendencia, como la alimentación de catálogos, o registro de información que posteriormente será procesada.

El patrón Domain Model lo utilizo para las operaciones rudas del negocio, para las reglas que tienen muchas validaciones o que pueden ser muy cambiantes y complejas.

El patrón Table Model, lo utilizo generalmente para sistemas con una complejidad que yo llamaría moderada y aplicando el patrón Command es posible tener procesos ciertamente poderosos y complejos sin perder mucho el hilo de que se hace en que parte.

Al final la elección de un patrón sobre de otro se resume mucho a la complejidad del proyecto y el tiempo que tenemos para desarrollarlo, aunque reitero que es posible hacer una combinación de un par de ellos y tener un buen resultado.

Próximamente tocaremos la capa de acceso a datos y la capa de vista, pero por el momento se termino la inspiración.

Un Saludo.