¿Los procedimientos almacenados violan la separación de tres niveles?

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?

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:

• Los datos de nivel: Consiste en tablas de bases de datos que se accede utilizando las cuatro operaciones de tabla estándar ( INSERT, UPDATE, DELETEy SELECT).
• Nivel lógico: consiste en procedimientos almacenados que implementan solo la lógica empresarial y acceden al nivel de datos utilizando solo los métodos descritos anteriormente.
• Nivel de presentación: consiste en un servidor web que ejecuta código que accede al nivel lógico realizando solo llamadas a procedimientos almacenados.

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.

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.

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/

Los procedimientos almacenados deben considerarse lenguaje ensamblador de la base de datos: para usar solo en las situaciones más críticas de rendimiento. Hay muchas maneras de diseñar una capa de acceso a datos sólida y de alto rendimiento sin recurrir a procedimientos almacenados; obtendrás muchos beneficios si te quedas con SQL parametrizado y un único entorno de desarrollo coherente.

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:

• El nivel de presentación , o capa de servicios de usuario, le da al usuario acceso a la aplicación.
• El nivel medio , o capa de servicios empresariales: consta de reglas empresariales y de datos.
• El nivel de datos , o capa de servicios de datos: interactúa con datos persistentes que generalmente se almacenan en una base de datos o en un almacenamiento permanente.

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:

Durante el ciclo de vida de una aplicación, el enfoque de tres niveles proporciona beneficios tales como reutilización, flexibilidad, capacidad de administración, mantenibilidad y escalabilidad. Puede compartir y reutilizar los componentes y servicios que crea, y puede distribuirlos a través de una red de computadoras según sea necesario. Puede dividir proyectos grandes y complejos en proyectos más simples y asignarlos a diferentes programadores o equipos de programación. También puede implementar componentes y servicios en un servidor para ayudar a mantenerse al día con los cambios, y puede volver a implementarlos a medida que aumenta el crecimiento de la base de usuarios, los datos y el volumen de transacciones de la aplicación.

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.

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.

Una capa es un mecanismo de estructuración lógica para los elementos que componen su solución de software; un nivel es un mecanismo de estructuración física para la infraestructura del sistema. ( Referencia )

En mi opinión, hay dos problemas principales con la construcción de la lógica empresarial en la base de datos:

1. 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.

2. 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).

Tuvimos este debate en nuestra oficina algunas veces, estaba favoreciendo el desarrollo de bases de datos, tengo la siguiente opinión al respecto

1. Si está utilizando Oracle Database, debe utilizar PL / SQL tanto como sea posible, porque seguramente las empresas que inviertan se apegarán a Oracle durante al menos incluso 10 años a partir de ahora. Mientras ayer en las aplicaciones estaba usando Oracle Forms, hoy formularios web .net, luego MVC, luego mañana usará angularjs y solo necesitará apis relajantes. Si su lógica máxima está en la base de datos, puede migrar fácilmente a las nuevas tecnologías front-end.
2. El desarrollo de bases de datos es muy rápido y muy eficiente en cuanto a rendimiento. Solo para darte una perspectiva. En nuestro proyecto había 7 desarrolladores de aplicaciones y un desarrollador de bases de datos, y el 80% de la lógica estaba en la base de datos.
3. Si está utilizando Oracle, puede utilizar utilidades para convertir directamente los procedimientos de su base de datos en Res full Api.

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.