Validación

Ya que hemos emprendido este camino de tratar de hacer las cosas de la mejor forma, no hay vuelta atrás. A partir de que cruzamos esa línea, nos cuestionaremos todo; sin embargo no es malo, por el contrario, resulta ser un proceso de madurez que al ser acompañado por aprendizaje, resulta motivador.

A veces los temas son conceptuales, y colisionan con nuestros conocimientos y principios sobre algo que ya sabemos, con lo que hemos estado trabajando desde siempre y que de repente se ve inmerso en una lista de dudas; por ejemplo ayer en una plática con el equipo de desarrollo, surgió la pregunta…

 

Donde ponemos la validación?

Y esta pregunta no se origino por el desconocimiento o por no saber cómo hacerlo, simplemente la duda surge porque la arquitectura del proyecto está formada por capas (basada en el patrón MVC), que tiene claramente definidas sus responsabilidades y que pueden realizar el proceso de validación todas y cada una de ellas.

 

Capas

UI.- Es la capa que da la cara al mundo, es por medio de esta capa que se recibe la información del usuario.

Controladores.-Hay dos diferentes tipos de clases que son el único medio de acceso a nuestro Framework, son las Clases Controladores o las Clases para atender Servicio. Ambas tienen acceso a un nivel que se encarga de realizar las validaciones, tanto de lógica de negocios como de datos.

Repositorios.- Envía la información recibida a la Capa de Acceso a datos, esta clase implementa el patrón de repositorio y es la única clase que saber cómo se realiza el acceso a datos, o sea encapsula dicha comunicación, para aislar a las capas superiores del origen de datos.

Model.- en este nivel encontramos el Entity Framework, el cual representa el Model y es el que en realidad realiza la plomería de comunicación al almacén de datos, ya sea para hacer persistentes los cambios o para recuperar información.

Base de datos: En la última capa encontramos a la base de datos, con las reglas de información, relaciones y datos que deben proporcionarse.

 

Tipos de validación

Aclaremos de ante mano que dentro de la validación común encontramos dos tipos las que son reglas de negocio, que resultaran altamente volátiles y la validación de datos, que muy pocas veces se modifica. Nos concentraremos en la validación de datos, ya que las reglas de negocio son un tema por sí mismas.

Si partimos de la idea que nuestra arquitectura fue diseñada para que las capas puedan ser reutilizas, para que no sean cohesivas y que puedan interconectarse en el futuro con clases nuevas que surjan en las capas anteriores y posteriores a ellas, no es recomendable caer en un escenario donde la validación sea obviada o excesiva. En situaciones como esta la validación de los datos debe hacerse lo más cerca de los datos en sí, de ser posible dentro de ellos mismos, como ocurre en la base de datos; de esta forma cuando usemos estos, sus reglas de validación estarían íntimamente relacionadas y serian reutilizables, por todo aquel que deba emplear estos.

 

Donde es más recomendable?

Estamos hablando de la Base de datos y de las entidades, las reglas de la base de datos se incorporan al Model, o sea nuestro EF, el cual efectúa estas validaciones. Sin embargo en nuestra arquitectura estamos usando Clases parciales, para poder extender las entidades del EF, con propiedades que no requerimos incluir en las entidades para que sean persistentes, pero que se requieren para la codificación, y los ViewModels que son una especie de entidades virtuales.

En estos dos casos, las propiedades nuevas que se añaden a las clases parciales y a los ViewModels, no tiene reglas de validación de los datos, nosotros debemos implementar el mecanismo correspondiente para que las reglas de validación de estos datos, se puedan reutilizar.

 

Solo ahí se pueden poner las validaciones?

En realidad, la preocupación principal es determinar si debemos hacer validación en todas las capas, o en cada capa solo debemos hacer un tipo de validación? Debemos asumir que la capa anterior cumplió con su tarea?

Hay otros puntos en relación con el tema que se deben tomar en consideración:

En la UI, para asegurarnos que la información proporcionada por el usuario sea la mínima necesaria, se requiere validar tipos de datos, formato adecuado, y datos requeridos. Esto se puede llevar a cabo con controles de captura. Nuevamente debemos aprender a separa las reglas de negocio de este tipo validaciones, las reglas de negocio no se deben poner en un control.

En el nivel de las clases controladoras, podemos aplicar un mínimo de validación solo por ser asertivos, verificando que nuestra clase reciba lo mínimo necesario para poder trabajar, sin embargo cuando se pueda debemos apoyarnos en la arquitectura de nuestro proyecto, esta tarea le correspondería a las clases de validación y de reglas de negocio.

En el repositorio no es necesario ya que este trabaja en intima relación con las controladoras o de servicios, y además el repositorio no puede ser accedido si no es a través de las a clases antes mencionadas, ya que su acceso está restringido, solo a clases dentro de nuestro Framework.

El ultimo bastión, la base de datos, aquí se deben establecer las reglas de tipos, datos que no deben ser nulos y datos que deben estar relacionados, ya sea por una relación maestro detalle, o por una relación de llaves foranes.

En un post próximo hablaré de las reglas de negocio.