¿Dónde debe implementarse la lógica de validación?

Al desarrollar mis interfaces (contratos) y las implementaciones concretas de ellos, tanto los modelos de datos como los repositorios, me pregunto dónde debe ir la lógica de validación. Parte de mí (que tiende a ganar) dice que la clase en sí misma debería ser responsable de su propia validación (longitud máx. De cadena, búferes de fecha, etc.), pero la otra parte de mí dice que esto debería trasladarse al repositorio porque depende en el almacén de persistencia, estos valores podrían cambiar en función de la implementación de su repositorio.¿Dónde debe implementarse la lógica de validación?

Creo que hay algo de validación que DEBE hacerse en el nivel de clase y creo que probablemente debería mantenerse junto y no cambiar incluso si el repositorio lo hace, por eso tiendo a mantenerlo en la clase.

Me refiero a la validación de la interfaz de usuario, pero esto nunca es suficiente, ya que gran parte de la validación de la IU se puede eludir.

Curioso lo que la gente piensa y el razonamiento detrás de esto.

Fuente

2009-03-26 Adam Carr

Las reglas de validación deben definirse en el nivel de clase de una manera abstracta que pueda 1) ejecutarse en el entorno nativo de la clase 2) representarse como reglas para otros entornos dependientes, como secuencias de comandos de UI o procedimientos de repositorio, según sea necesario .

Esto le permite tener la lógica centralizada donde debería estar, en la clase y la validación auxiliar en la UI y en cualquier otro lugar - fácil de mantener ya que se deriva de la clase en lugar de ser una lógica desconectada que vive en una ubicación desconectada. Victoria general.

Fuente

2009-03-26 04:00:12 chaos

Ninguno si debe derivarse de la base de datos. Más bien, viceversa, si uno va a conducir al otro. No dicte el comportamiento del usuario desde su esquema de base de datos. Además, no desea que sus pruebas de unidad de clase dependan de las conexiones y los artefactos de la base de datos. – dkretz

Ciertamente, en un entorno web cualquier cosa que coloque en el lado del cliente para la validación se puede pasar por alto.

Generalmente pongo la validación en la clase. Luego pídales a los incubadores que levanten o hagan una excepción, o si prefiere usar un valor de retorno. Utilizo excepciones en el mundo .Net porque puedo tener un conjunto de excepciones personalizadas con mensajes de reglas de validación claras devueltas al consumidor/cliente.

Fuente

2009-03-26 04:01:31

He tenido mucho éxito poniendo toda mi validación lo más cerca posible del lugar donde se guardarán los datos en la capa empresarial. P.ej. en los establecedores de propiedad. Esto garantiza que solo esté pasando datos válidos dentro de su capa empresarial y también garantiza que la interfaz de usuario recibirá datos válidos de la capa empresarial.

Hasta cierto punto, esto también evita la necesidad de mucha validación en su capa de datos si su código siempre pasa a través de su capa de negocios.

La única regla sobre la que sería dogmático es nunca confiar en la validación del nivel de IU, ya que esta capa es la más fácilmente comprometida (especialmente en una aplicación web). La validación de nivel de interfaz de usuario es un edulcorante solo para que su experiencia de usuario sea más amigable.

Fuente

2009-03-26 04:03:38

Un contrato (interfaz) entre dos partes dice, A y B de manera que ambos tienen ciertas obligaciones. ¿Qué dice el contrato? ¿Se supone que B debe recibir datos validados? Si ese es el caso, B no debería implementar la validación. Pero, ¿y si A es la interfaz de usuario? Claramente no quieres poner la validación allí. Por lo general, es mejor presentar a un tercero, digamos C. A tiene un contrato con C, que a su vez tiene un contrato con B. B espera datos validados. A podría enviar basura. C realiza la validación.

Si los contratos están bien diseñados, esto casi nunca es un problema. Revistir el contrato y colocar obligaciones en cada una de las partes. Si una determinada parte tiene demasiadas obligaciones, presente a un tercero.

Fuente

2009-03-26 04:18:31 Nikhil

La validación debe ser parte del objeto. Haga que el entorno sea parte de los parámetros para el constructor del objeto. De esta forma, puede personalizar la lógica de validación para el entorno, pero el objeto no tiene que determinar dónde se está ejecutando.

Siempre utilizo la validación de UI a pesar de que en el mejor de los casos es una seguridad débil. Ahorra viajes redondos al servidor (el ancho de banda sí se suma) y te permite ser más amigable con los mensajes de error. Pero nunca debería ser la única capa de validación.