La arquitectura de mis proyectos MVC.

Dentro del desarrollo de software existen diferentes niveles de abstracción, cuando empezamos a escribir código lo hacemos al más bajo nivel o sea al nivel de los requerimientos, de las descripciones detalladas que nos permiten codificar esa lógica para que después forme parte de algo mucho más grande.

El nivel más alto de abstracción de un sistema es aquel donde podemos ver toda la estructura, sus componentes y las relaciones que estas partes tienen entre si; si quieren podemos decir que el termino ARQUITECTURA DE SOFTWARE es una analogía que hace referencia a la construcción de edificios. Algunos prefieren decirle diseño del software…

 

Beneficios de estos diagramas.

Al observar un diagrama es posible comprender como se debe estructurar, de qué manera fluye; incluso podemos identificar las partes independientes y aquellas que heredan y que pueden ser dependientes.

Existen muchas formas de representar este tipo de diseños, algunos se basan en los datos, otros en las operaciones, el flujo de la lógica, etc. Lo más importante es que estos diagramas pueden servir como guía para todos los implicados en el desarrollo de un sistema.

 

El diagrama.

Este diagrama en particular, es general, se enfoca en las relaciones y en las partes que interactúan para la creación de un proyecto usando el patrón MVC, de la versión 5 de ASP.NET MVC.

A continuación les explicare el modelo:

1. Nuestra aplicación debe seguir el patrón MVC, por lo tanto se espera que contenga Controladores, Modelos y Vistas, mismos que podemos ver en los cuadros verdes.
2. ASP.NET nos ofrece todo el entramado para que nuestra aplicación funcione en la plataforma, he resaltado 3 partes en color azul oscuro: Ruteo, Mapeo y View Engine.
3. Siguiendo los consejos que les he estado publicando en los artículos anteriores, he recurrido a bibliotecas públicas instaladas desde NuGet, para reforzar la seguridad de mi aplicación; estos los pueden componentes intervienen en el mecanismo de Ruteo, validando los permisos del perfil al cual pertenece el usuario que realiza la solicitud.
4. Así mismos, una vez que se ha verificado el acceso, se aplican reglas de validación de datos para asegurarnos que la información que ha llegado cumple con nuestras reglas y de esta manera prevenir que algún usuario malicioso nos envié datos no validos.
5. Una vez que estos datos han sido validados el flujo de la aplicación lo toma el controller, en este momento la lógica del Controlador determina si se debe continuar o si deberá ser re direccionado, ya sea por un error o por condiciones especiales. El Controller deriva de una clase base que contiene código reutilizable.
6. Si el Controlador determina que el flujo debe seguir, los datos pasaran a un servicio para que se haga cargo de la acción CRUD correspondiente; hasta este momento los datos se encuentran en un ViewModel.
7. El servicio recibe el VM los procesa según la lógica de negocio, lo convierte a una entidad que el repositorio pueda usar y se lo envía para tomar las acciones pertinentes. El servicio implementa una interface predefinida, que me asegura que todos los servicios mantengan la misma estructura así como un mínimo de métodos requeridos para responder las acciones del CRUD.
8. El repositorio por su parte es una clase Genérica que es capaz de adaptarse mecanismo de persistencia que se haya configurado, pudiendo ser MySQL, SQL, etc. Esta clase contiene los métodos básicos del CRUD; si se requiere algún método especial, es posible extenderla para añadir estos métodos personalizados.
9. Si se trata de una consulta el repositorio responderá con una entidad o una colección de estos; el servicio recibe estas entidades, las convierte en VM y las devuelve al controlador. El controlador envía estos datos al ViewEngine encapsulados en el VM para que sean convertidos en una respuesta usando la vista correspondiente.
10. La vista convertida en HTML, CSS, JavaScript, etc. es enviada de regreso al usuario que ha realizado la solicitud.

Comentario final.

El diagrama es muy sencillo así como la descripción, sin embargo vale la pena hacer notar que se trata de un esquema de codificación muy estandarizado, que respeta convenios propios de este diseño, a tal grado que incluso he logrado desarrollar una herramienta que genera el código base de toda la aplicación, a partir del diseño de la base de datos.

Esto nos permite ahorrarnos más del 30% de tiempo de desarrollo total, en ciertos casos incluso hasta un 50%; primero porque no hay sorpresas, cualquiera que conozca la arquitectura empleada y  los convenios, sabrá donde se encuentra lo que desea modificar; el código generado automáticamente es 100% libre de errores de codificación, además el mantenimiento como podría ser por ejemplo: añadir un campo mas a la base de datos, únicamente requiere añadir el campo a la tabla y añadir la propiedad a la entidad y al VM correspondiente y listo.

Que les parece? Más adelante seguiré compartiendo con ustedes más de este diseño, espero que les sea de utilidad.

Suerte.