Algunos de mis colegas me han dicho que tener lógica empresarial 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 comercial.
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 múltiples 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 asemejan 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 hacer cualquiera de los dos con éxito tiene en común es la necesidad de cuidado, disciplina y un entendimiento 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 , DELETE y SELECT ). Este es un modelo perfectamente aceptable, pero viene con algunas compensaciones. La lógica empresarial 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 hacerse "por la vía difícil" mediante un nivel lógico fuera de la base de datos. Lo que abandonas es la capacidad de mover fácilmente cualquier nivel a otro poco de tecnología e implementación despreocupada (es decir, debes tener mucho cuidado de que los niveles no utilicen las instalaciones que están disponibles en la base de datos pero fuera de sus interfaces definidas) .
El hecho de que este tipo de cosas y las compensaciones que esto conlleve o no sean aceptables en una situación determinada es algo que usted y sus colegas deben determinar utilizando su criterio.
Los procedimientos almacenados son lo suficientemente poderosos como para permitirle codificar una violación de la separación de tres niveles al llevar la lógica empresarial a la capa RDBMS. Sin embargo, esta es su decisión, no una falla inherente de los procedimientos almacenados. Puede limitar sus SP a 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 activadores) para contener la lógica de negocios. Esto sucede cuando su aplicación necesita producir una gran cantidad de agregaciones de datos sobre la marcha que tocan millones de filas. En casos como ese, los desencadenantes pueden configurarse para mantener datos pre-agregados para el uso de la capa empresarial. Esto se debe hacer solo en situaciones en las que sin la agregación previa, su aplicación sería inaceptablemente lenta.
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 comerciales, podría 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 intermedio o la capa de servicios empresariales, consta de reglas de datos y de negocios. Sin embargo, a veces es muy importante cambiar las operaciones básicas y / o las reglas de datos que se realizan en 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 brinda beneficios tales como reutilización, flexibilidad, capacidad de administración, capacidad de mantenimiento y escalabilidad. Puede compartir y reutilizar los componentes y servicios que cree, y puede distribuirlos en 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 ayudarlo a mantenerse al día con los cambios, y puede volver a implementarlos a medida que aumente 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 de base de caso que tiene compensaciones en sí mismo. Sin embargo, las pautas de diseño de Microsoft de modelo de arquitectura de tres niveles recomienda mantener tu lógica empresarial en el nivel intermedio.
El consejo de Atwood de 2004 sigue siendo cierto hoy en día, solo que ahora también tenemos el beneficio de ORM.
Los procedimientos almacenados deben considerarse lenguaje ensamblador de base de datos: para Utilizar solo en las situaciones más críticas de rendimiento. Hay bastantes de formas para diseñar una capa de acceso a datos sólida y de alto rendimiento sin recurrir a procedimientos almacenados; te darás cuenta de muchos beneficios si se adhiere a SQL parametrizado y un solo desarrollo coherente medio ambiente.
Nivel realmente significa una máquina diferente, capa significa una 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 empresarial 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 conforman 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 creación de lógica empresarial en la base de datos:
Código y bibliotecas: encontrará menos programadores capaces de programar en SQL, PL / SQL, TSQL, etc. que en C #, Java, etc. Los lenguajes de programación también tienen la ventaja de grandes IDE, grandes 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 con una más potente, que es bastante costosa (un servidor con 64 GB de RAM); Las bases de datos relacionales se escalan horizontalmente muy mal, e incluso con mayores gastos. Mientras que, con la lógica empresarial en un servidor OO, se 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 atrás, estaba favoreciendo el desarrollo de bases de datos, tengo una vista posterior en él
El argumento más sólido que dan los desarrolladores de aplicaciones 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á utilizando Oracle por qué cambiará a otra tecnología, en lugar de eso, las posibilidades de que la lógica de la aplicación quede obsoleta son más esperadas. El problema es, en su mayoría, falta el talento del recurso de la base de datos, en su mayoría los chicos comienzan con sitios web simples donde están usando mysql o sqlserver. Luego, estos individuos se convierten en clientes mayores y tienen un vínculo emocional con la capa de aplicación :) que ni siquiera quieren entender o debatir.
Lea otras preguntas en las etiquetas business-logic layers separation-of-concerns n-tier stored-procedures