Capas con Entidades relacionadas (2 de 3)

Esta es la segunda parte del artículo donde se ejemplifica como usar la arquitectura de capas con entidades relacionadas.

Ya hemos presentado en el articulo previo la capa del doman Model, aun que aun debe ser modificada para incluir todos los controles que se requerirán por los cambios que introduciremos; además en esta segunda parte vamos a terminar con las capas superiores de este modelo.

Nuevos requerimientos.

Para garantizar la integridad de la información que estaremos manejando, debemos incluir en nuestro ejemplo el uso del objeto de transacciones de ADO.

Este mecanismo se implementara en la capa de servicios, pero es necesario modificar lo que ya habíamos creado, la interface de IRepository:

Sera necesario agregar dos parámetros para nuestro método Grabar de la interface de Repository. Mismos que se deben agregar al método grabar de las clases que la implementan:

Nota: Esto debe hacerse en los dos repositorios.

Continuación Tutorial

1.- Para continuar con la capa de servicios, necesitamos una carpeta llamada Servicios, y dentro de esta creamos un folder para ViewModels:

2.- Los ViewModels son una simple representación de las entidades, para mantener la independencia de cada capa:

3.- Dentro de la carpeta de servicios crearemos la clase que se encarga de llevar a cabo las transacciones a nivel del Model:

Este es el código del método RealizaTransaccion que aparecía cerrado en la imagen anterior:

Observación: El objetivo de este código es mantener en un solo punto el control de la conexión, así como de la transacción, para garantizar la atomicidad de la operación. A pesar que se creó publica, lo ideal es que se mantenga interna al igual que las clases de repositorio, puesto que solo las clases a nivel de la API deben ser visibles y de esta forma se evitan accesos indebidos violando la integridad de nuestra aplicación.

4.- Al igual que en el ejemplo anterior, debemos crear las clases para poder convertir una entidad en una ViewModel, mismas que crearemos como extensiones de las entidades, en la carpeta de entidades:

Extensión de cuentas

Extensión de Movimientos

5.- Según nuestra misma arquitectura ahora debemos crear la solicitud y la respuesta, en esta ocasión vamos a preparar nuestro código para poder implementar más de una clase de respuesta, esto es posible creando una clase base que puede ser implementada por cada clase que deba contener esas propiedades:

6.- Si fuera necesario crear otra clase respuesta, por ejemplo para enviar todas las cuentas, podemos crear una clase usando la misma estructura.

7.- Para llevar a cabo las acciones inherentes al manejo de la cuenta vamos a implementar un mecanismo de mensajes, este patrón establece que por cada solicitud debe haber una respuesta, aun que una clase respuesta puede servirnos para responder a mas de una solicitud; las acciones a realizar serian:

Crear la cuenta: Es la acción de abrir una cuenta.

Solicitud

Respuesta

Consultar cuenta: Es la acción de solicitar el estado de cuenta.

Abonar al saldo: Es la acción de sumar efectivo al saldo de la cuenta.

Retirar efectivo: Es la acción de retirar efectivo de la cuenta.

Transferir a otra cuenta: Es la acción de usar el saldo de la cuenta para realizar una transferencia de efectivo a otra cuenta. (Pudiendo ser un pago)

Al terminar tendremos nuestro proyecto de esta manera:

Hasta aquí hemos creado el código de la capa intermedia, ya nos falta poco para poder ver en ejecución este nuevo ejemplo.

Solo nos queda pendiente una entrega, donde podrán ver como se crea una cuenta.