OT: Donde incluir las reglas de negocio

[maxriel]

Amigos,

Solo por curiosidad, me gustaría saber cuanto de reglas de negocio (cálculos, validaciones, etc.) ponen en la aplicación cliente (ej: la App en VFP) y cuanto ponen en la BD (SPs, Triggers, etc...).

Me encuentro con desarrollos donde el motor de BD solo lo usan como un repositorio y otros que sobre-explotan el motor SQL con cuanta característica tenga.

En una época aconsejaban usar SQL ANSI estandard para mantener la independencia del motor pero a la vez esto desperdicia características importantes.

Que opinan?

saludos

 

[Fernando D. Bozzo]

Hola maxriel:

Si ponés las reglas de negocio en la base de datos:

• Tu aplicación es más escalable
• Otros fornt-ends (web, java, etc) pueden reemplazar en algún momento al front-end FoxPro
• Podés ofrecer cuando quieras o necesites web-services, simplemente creando el envoltorio SOAP con cualquier lenguaje
• Podés ofrecer esos servicios o procesos a otras aplicaciones, incluso reutilizarlos en otros servicios o procesos, incluso batch
  
• Se te complica un poco el manejo de datos en tu aplicación, porque no vas a poder usar un grid para mostrar toda la tabla (que además no es una buena práctica) y vas a tener que permitir el acceso a los datos mediante consultas y nunca trayendo todo sin filtrar
• Toda la lógica de la aplicación (no-negocio) tiene que tener en cuenta este modo de acceso, que no es lo mismo que el acceso local
  

 
Si ponés las reglas de negocio en la aplicación:

• Tu aplicación no será escalable
  
• Solo esa aplicación podrá usar las reglas de negocio
• Tenés más libertad para el manejo de datos dentro de la aplicación
  

Hay varias cosas más, pero es lo primero que se me ocurrió.

Saludos.-

[MALKASOFT ADPI: http://www.developervfp.blogspot.com/]

Hola solo para reforzar con lo que dijeron antes que yo, es que cualquier herramienta de desarrollo solo es para uso de interfaz de usuario.

revisa este link Programación por capas

Saludos; 

Ing. Russvell Jesus Soto Gamarra 

Canal YouTube: http://www.youtube.com/rycjesusrj

Blog: http://developervfp.blogspot.mx/

Framework Multi-conexion v6.0 trabaja cualquier base de datos

(SQLServer, MySQL, Firebird, MariaDB, PostgreSQL, Oracle y etc.) 

http://www.youtube.com/watch?v=PCCZvCaet74

[Carlos Miguel FARIAS]

Todo lo que pongas en SP en la BD, está disponible por terceros, salvo que logres que los SP este cifrados o compilados en forma externa, eso es algo que si mal no recuerdo permite SQL Server.

En mi caso, lo que si o si debe estar en la bd son las vistas de consultas (cualesquiera) o cualquier otro proceso que reduzca el flujo de datos a través de la red.

Las reglas de negocio deberían estar ubicadas en el punto donde se evita que circulen datos "no apropiados" por la red.

Por ejemplo. Si armo una transacción con datos de varios formularios (muchos datos), los envío al SGBD para que me los rechace por incompletos, inconsistentes, etc. fue una transferencia "inútil".

Esto último es como si estuvieras en una intranet (cliente-delgado = navegador) donde es poco práctico o inseguro poner código de validación vía JS.

Además, los SP se harían bastante "pesados", teniendo en cuenta que generalmente, el lenguaje de éstos no es tan versátil como un lenguaje de programación de los comúnmente usados (vfp, C#, python, etc.) en la aplicación de escritorio.

Al menos, esos son puntos que evalúo al momento de hacer la aplicación.

Otra cosa a tener en cuenta, si lo codificas en tu lenguaje de programación habitual, te va a ser más fácil migrar la regla a otro lenguaje de programación de reemplazo, si lo programas en SP de un SGBD, te va a ser más dificil migrar el código al SGBD diferente.

Lo que tienes que sopesar es si quieres que tu aplicación en el lenguaje X que actualmente usas, pueda trabajar sobre diferentes SGBD o el SGBD que seleccionaste ahora, sea manejable desde cualquier lenguaje (indefinido) futuro.

Estos son puntos adicionales a considerar a los que comento Fernando 

Saludos: Miguel, La Pampa (RA)

[maxriel]

Ok, gracias a todos por las respuestas,

Si, sopoeso ventajas y desventajas entre centralización de reglas y disponibilidad multi-cliente VS. versatilidad y recursos del lenguaje de programación.

Estoy analizando PostgreSQL en el cual veo que se pueden programar los SP en Python. Esto le daría algo más de vuelo a los SP clásicos.

También veo que para la versión 3 de Firebird prometen también poder utilizar lenguajes externos para escribir los SP.

Estas dos BD dentro del mundo Open Source.

Otra alternativa sería desarrollar "middleware" o capa intermedia tipo interfaz REST en algún soporte web que a su vez se comunique con la BD.

En fin, las alternativas son variadas.

seguiremos buscando cual es la mejor.

saludos