Donde validar (Capa de datos - Reglas de negocio)

"El principiante" escribió en el mensaje
news:%

Gracias por sus opiniones tan interesantes.

De ellas me arriesgo a concluir que en terminos practicos lo que me

conviene

es:

1) Tener en la base de datos las restricciones CHECK, valores por defecto,
claves primarias y similares que le den
una integridad de datos (como dice el compañero de arriba).

2) Tener una capa de validacion de datos llamada desde la interfaz pero NO
que resida en la base de datos (pues no seria necesario). Algo asi como

el

ejemplo de controlar el limite de credito de un cliente al hacer una nueva
factura. Esta capa de datos se auxiliaría de uno que otro procedimiento
almacenado que se defina para agilizar procesos que lo requieran pero
conceptualmente la validacion la haria la aplicacion.

3) Lo que habria que limitar es el acceso a los datos desde fuera de la
aplicacion para evitar que se violen las reglas de negocio que se hayan
definido en la capa intermedia, salvo que sea el administrador de la BD

Hola, Principiante:

No se si será correcto (estoy nuevo en esto de SQL Server, y soy bastante
malo asumiendo "dogmas").

Hasta donde lo entiendo, uno de los objetivos de la separación en capas es
permitir cambiar la implementación de una función sin que este cambio
produzca efectos adicionales en el resto del sistema. Y el objeto de esta
práctica es minimizar el costo del cambio.

Supon que una organización le niega el crédito a los clientes cuyo limite
está excedido, otra a los que tienen una factura vencida y una tercera a
quienes tengan mas de tres facturas pendientes.

Cuando diseñas tu aplicación, puedes tomar en cuenta una cantidad de maneras
de validar la aprobación de un crédito, y permitir que el usuario, en el
programa de configuración parametrice el mecanismo. Esto es lo que
normalmente se hacia en tiempos de los sistemas monolíticos.

La solución que le he dado a este tipo de problemas en mis aplicaciones
"pequeñas" es utilizar Scripts.

Pero si dispones de una herramienta como SQL Server, puedes confiar este
tipo de validaciones a la BD, implementandolas como funciones de usuario o
como procedimientos almacenados (prefiero éstos). La ventaja de este método
es que permites que el cliente reconfigure sus políticas mediante un simple
cambio en la definición de la UDF o del SP: te ahorras todos los
inconvenientes de reconstruir y redistribuir tu aplicación.

Hay "pequeñas validaciones" (que el cliente exista, que existan los
productos, que la condición sea valida) que deben ser ejecutadas desde la
forma. La forma, por lo general, es un pequeño componente de una aplicación
cuyas entidades estan implementadas como clases. La responsabilidad de la
forma es pedirle a cada una de las clases que determine la validez de cada
entrada del usuario. De esta manera mantienes a la forma ignorante (e
independiente) de los detalles de implementación. Como norma general,
considero un error de diseño cualquier operacion de acceso a una BD que
aparezca en el código de un formulario.

Por lo general es buena idea reducir la cantidad de accesos a la BD. En
todas las aplicaciones hay cantidad de tablas pequeñas y relativamente
estáticas (cosas como definiciones de impuestos, descuentos, almacenes,
condiciones de credito): es bueno que esas tablas sean cargadas en algun
tipo de colección especializada, que asumirá la responsabilidad de validar
las entradas y proveer a sus clientes de la información requerida.

Salud!

Leonardo
mvp vb