Algunos colegas míos me han dicho que tener lógica de negocios en los procedimientos almacenados en la base de datos viola la arquitectura de separación de tres niveles, ya que la base de datos pertenece a la capa de datos, mientras que los procedimientos almacenados son lógica de negocios.
Creo que el mundo sería un lugar muy sombrío sin procedimientos almacenados.
¿Realmente violan la separación de tres niveles?
business-logic
n-tier
layers
stored-procedures
separation-of-concerns
Tulains Córdova
fuente
fuente
Respuestas:
Sus colegas están combinando arquitectura con implementación.
La idea detrás de una aplicación de varios niveles es simplemente que se divide en partes que encapsulan ciertos tipos de procesamiento (almacenamiento, lógica de negocios, presentación) y se comunican entre sí mediante interfaces bien definidas. Así como es posible hacer con éxito cosas que se parecen a la programación orientada a objetos en lenguajes no orientados a objetos, es posible hacer lo mismo con múltiples niveles dentro de un entorno, como un servidor de base de datos. Lo que tienen en común cualquiera de los dos con éxito es la necesidad de atención, disciplina y comprensión de los compromisos involucrados.
Veamos una aplicación de tres niveles donde dos de los niveles se han implementado en una base de datos:
INSERT,UPDATE,DELETEySELECT).Este es un modelo perfectamente aceptable, pero viene con algunas compensaciones. La lógica de negocios se implementa de una manera que le brinda un acceso rápido y fácil al nivel de datos y puede permitir hacer cosas que tendrían que hacer "de la manera difícil" por un nivel lógico fuera de la base de datos. Lo que renuncia es la capacidad de mover fácilmente cualquier nivel a otro tipo de tecnología e implementación sin preocupaciones (es decir, debe tener mucho cuidado de que los niveles no utilicen las instalaciones disponibles en la base de datos sino fuera de sus interfaces definidas) .
Si este tipo de cosas y las compensaciones que conlleva son aceptables en una situación dada es algo que usted y sus colegas deben determinar utilizando su criterio.
fuente
SELECTes directamente de las tablas (el nivel de datos), el modelo se ha roto.Los procedimientos almacenados son lo suficientemente potentes como para permitirle codificar una violación de la separación de tres niveles al incorporar la lógica empresarial en la capa RDBMS. Sin embargo, esta es su decisión, no un defecto inherente de los procedimientos almacenados. Puede limitar sus SP para atender las necesidades de su capa de datos, mientras mantiene la lógica de su aplicación en la capa de aplicación de su arquitectura.
Hay una excepción rara pero importante a la regla de separación, cuando necesita procedimientos almacenados (específicamente, un grupo de desencadenantes) para contener la lógica empresarial. Esto sucede cuando su aplicación necesita producir muchas agregaciones de datos sobre la marcha que tocan millones de filas. En casos como ese, se pueden configurar activadores para mantener datos agregados previamente para el uso de la capa empresarial. Esto debe hacerse solo en situaciones en las que sin una agregación previa su aplicación sería inaceptablemente lenta.
fuente
El consejo de Atwood de 2004 suena cierto aún hoy, solo que ahora también tenemos el beneficio de ORM.
http://blog.codinghorror.com/who-needs-stored-procedures-anyways/
fuente
Breve resumen: Realmente depende de su uso de los procedimientos almacenados y los requisitos comerciales.
Hay una serie de proyectos que utilizan una arquitectura de tres niveles y, dependiendo de la naturaleza de los requisitos del negocio, puede ser necesario cambiar algunas operaciones a un nivel de datos.
Hablando de terminología, en términos generales, estos niveles se describen como:
Por lo general, para la arquitectura dada, el nivel medio o la capa de servicios comerciales, consiste en reglas comerciales y de datos. Sin embargo, a veces hace una gran diferencia cambiar las operaciones de base de conjunto pesado y / o las reglas de datos para que se realicen en el nivel de datos , a través de un conjunto de procedimientos almacenados.
Los beneficios de los diseños de tres niveles son:
Por lo tanto, es realmente un enfoque basado en casos que tiene compensaciones en sí mismo. Sin embargo, las pautas de diseño de Microsoft del modelo de arquitectura de tres niveles recomiendan mantener la lógica de su negocio en el nivel medio.
fuente
Nivel realmente significa máquina diferente, capa significa separación lógica diferente. Con los procedimientos almacenados, tiene la capa de datos y (al menos parte de) la capa de lógica de negocios en el mismo nivel. Poner la lógica de negocios en los procedimientos almacenados viola la arquitectura de 3 cansados, pero es cuestionable si viola una arquitectura de 3 capas; Una cosa segura es que no es un buen ejemplo de separación de preocupaciones.
En mi opinión, hay dos problemas principales con la construcción de la lógica empresarial en la base de datos:
Código y bibliotecas: encontrará menos programadores que puedan programar en SQL, PL / SQL, TSQL, etc. que en C #, Java, etc. Los lenguajes de programación también tienen la ventaja de excelentes IDE, excelentes bibliotecas y marcos.
Escalabilidad horizontal: la única forma de escalar su sistema es cambiando el servidor físico en el que se encuentra la base de datos por uno más potente, que es bastante costoso (un servidor con 64 GB de RAM); Las bases de datos relacionales escalan horizontalmente muy mal, e incluso a mayores gastos. Mientras que, con la lógica empresarial en el servidor OO-built, puede escalar horizontalmente bastante bien colocando el servidor en muchos nodos (en Java, muchos servidores de aplicaciones lo admiten).
fuente
Tuvimos este debate en nuestra oficina algunas veces, estaba favoreciendo el desarrollo de bases de datos, tengo la siguiente opinión al respecto
El argumento más fuerte que los desarrolladores de la aplicación le dan es que la lógica de negocios debe ser independiente de la base de datos para que pueda cambiarla fácilmente. Creo que si una empresa está usando Oracle, ¿por qué cambiarán a otra tecnología? En cambio, es más probable que las posibilidades de que la lógica de la aplicación sea obsoleta. El problema es sobre todo el nuevo talento del recurso de base de datos que falta, la mayoría de los chicos comienzan con sitios web simples donde están usando mysql o sqlserver. Estos chicos se convierten en líderes senior y tienen un apego emocional con la capa de aplicación :) que incluso no quieren entender o debatir.
fuente