¿Merece la pena poner la lógica de negocio en la BBDD?
Lo digo por el tema de si cambias de BBDD y para llevar un control de versiones mejor.
Edito:
Me refiero a los triggers, procedures, restricciones, procesos que se lanzan a una determinada hora, etc. que hacen que nuestra aplicación sea consistente.
P.D. Los datos de la aplicación está claro que se guardarían en la BBDD para hacerlos consistentes.
no sé si esta bien formulada la pregunta, al final los datos los tendrás que guardar en una base de datos si quieres que persistan en el tiempo...
si te preocupa cambiar de base de datos en un futuro, puedes usar un ORM para que te sea más fácil hacer el cambio
http://es.wikipedia.org/wiki/Mapeo_objeto-relacional
creo que al final lo ideal es que si usas un framework y lo tienes que cambiar o actualizar, cuanto menos dependa de este mejor para que un simple cambio no desmorone tu proceso de ventas.
algunos dicen de tener la lógica de negocio en un servicio o API para tenerlo separado de la app principal.
http://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas
Los datos de la aplicación está claro que se guardarían en la BBDD para hacerlos consistentes.
Pero lo que yo busco es donde hacer el código de los procedure, triggers y funciones que cuando estudias te dicen que los hagas en la BBDD pero luego en la práctica no lo veo claro para luego mantener ese código por si cambias de BBDD o lo quieres mantener bajo control de versiones.
en mi opinión creo que más fácil de entender, si estas reglas están en un controlador dentro del repositorio de código.
la verdad es que no sé que compatibilidad hay de procedures, triggers y funciones entre distintas bases de datos, pero creo que no deberías estar limitado a eso a la hora de elegir una base de datos.
Es la pregunta que me hago siempre que empiezo una aplicacion nueva.
Una base de datos bien organizada, con sus triggers y restricciones puede ahorrar mucho código y comprobaciones extra, pero cada aplicación es un mundo.
Sin duda alguna no es el controlador (de MVC). Revisa nuevamente la documentación.
El controlador se encarga de coordinar acciones entre las vistas y el modelo. Seguramente adaptando/transformando tipos de datos y haciendo verificaciones sobre el "uso" del modelo, nunca sobre la lógica.
La lógica de la aplicación es un poco amplio, Miquel se refería seguramente a la lógica propia del problema que está muy relacionada con los datos del mismo. Esto es justamente para lo que se definió "el modelo", que es una representación (siempre limitada, por eso es un modelo y no la realidad).
Lo digo por el tema de si cambias de BBDD y para llevar un control de versiones mejor.
Edito:
Me refiero a los triggers, procedures, restricciones, procesos que se lanzan a una determinada hora, etc. que hacen que nuestra aplicación sea consistente.
P.D. Los datos de la aplicación está claro que se guardarían en la BBDD para hacerlos consistentes.
27/11/2013 13:18
si te preocupa cambiar de base de datos en un futuro, puedes usar un ORM para que te sea más fácil hacer el cambio
http://es.wikipedia.org/wiki/Mapeo_objeto-relacional
creo que al final lo ideal es que si usas un framework y lo tienes que cambiar o actualizar, cuanto menos dependa de este mejor para que un simple cambio no desmorone tu proceso de ventas.
algunos dicen de tener la lógica de negocio en un servicio o API para tenerlo separado de la app principal.
http://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas
27/11/2013 13:55
Pero lo que yo busco es donde hacer el código de los procedure, triggers y funciones que cuando estudias te dicen que los hagas en la BBDD pero luego en la práctica no lo veo claro para luego mantener ese código por si cambias de BBDD o lo quieres mantener bajo control de versiones.
27/11/2013 15:03
en mi opinión creo que más fácil de entender, si estas reglas están en un controlador dentro del repositorio de código.
la verdad es que no sé que compatibilidad hay de procedures, triggers y funciones entre distintas bases de datos, pero creo que no deberías estar limitado a eso a la hora de elegir una base de datos.
27/11/2013 13:33
Una base de datos bien organizada, con sus triggers y restricciones puede ahorrar mucho código y comprobaciones extra, pero cada aplicación es un mundo.
27/11/2013 15:40
¿A día de hoy hay alguna manera útil de incluir los triggers en el control de versiones y tener test unitarios de todo eso?
27/11/2013 13:13
27/11/2013 14:50
27/11/2013 15:32
El controlador se encarga de coordinar acciones entre las vistas y el modelo. Seguramente adaptando/transformando tipos de datos y haciendo verificaciones sobre el "uso" del modelo, nunca sobre la lógica.
La lógica de la aplicación es un poco amplio, Miquel se refería seguramente a la lógica propia del problema que está muy relacionada con los datos del mismo. Esto es justamente para lo que se definió "el modelo", que es una representación (siempre limitada, por eso es un modelo y no la realidad).
27/11/2013 21:24