sql - programacion - ¿Debería la capa de acceso a datos contener lógica de negocios?

capa de servicios java (12)

He visto una tendencia a mover la lógica de negocios fuera de la capa de acceso a datos (procedimientos almacenados, LINQ, etc.) y hacia una capa de componentes de lógica de negocios (como los objetos C #).

¿Es esta considerada la manera "correcta" de hacer las cosas en estos días? Si es así, ¿significa esto que algunas posiciones de desarrollador de bases de datos pueden eliminarse en favor de más posiciones de codificación de nivel medio? (Es decir, más código c # en lugar de procedimientos almacenados más largos).

El mundo perfecto no existe. Se trata de la elegancia frente a lo que funciona mejor. La ejecución de consultas SQL complejas dentro de las capas de acceso a datos es mucho más productiva que hacer que un servicio le solicite datos muchas veces y luego fusionarlos y transformarlos. Cuando realiza consultas complejas, está poniendo lógica de negocios en esas consultas.

Es probable que siempre haya algún nivel de lógica empresarial en la capa de datos. Los datos en sí son una representación de algo de esa lógica. Por ejemplo, las claves primarias a menudo se crean en base a reglas de lógica de negocios.

Por ejemplo, si su sistema no permite que un pedido tenga más de un cliente es parte de la lógica de negocios, pero también está presente (o debería estar) en la capa de datos.

Además, algunos tipos de reglas de negocios se hacen mejor en la base de datos por razones de eficiencia. Estos suelen ser procedimientos almacenados, y por lo tanto existen en la capa de datos. Un ejemplo podría ser un disparador que se dispara si un cliente ha gastado más de $ X en un año, o si un envío es diferente de un envío de factura.

Muchas de estas reglas también pueden manejarse en la capa de negocios, pero también necesitan un componente de la capa de datos. Depende de donde se encuentre su manejo de errores.

La lógica de acceso a los datos pertenece a la capa de acceso a los datos, la lógica de negocios pertenece a la capa de negocios. No veo cómo mezclar los dos podría considerarse una buena idea desde el punto de vista del diseño.

La lógica de negocios en la capa de datos era común en las aplicaciones cliente / servidor, ya que realmente no había una capa de lógica de negocios per se (a menos que realmente pudiera, seriamente evitar que alguien se conecte a la base de datos fuera de la aplicación). Ahora que las aplicaciones web son más comunes, está viendo más aplicaciones de 3 y 4 niveles (cliente + servidor web + servidor de aplicaciones + servidor de base de datos), y más compañías siguen las mejores prácticas y consolidan la lógica empresarial en su propio nivel. No creo que haya menos trabajo para los desarrolladores de bases de datos, probablemente se convertirán en los que escriban la capa lógica empresarial (y dejen que una herramienta ORM escriba la mayor parte de la capa de la base de datos).

La razón por la que he visto esta tendencia es que LINQ y LINQ to SQL ORM le ofrecen una buena alternativa de tipo seguro a los procedimientos almacenados.

Lo que es "correcto" es si te beneficias al hacerlo personalmente.

La separación de capas no significa automáticamente que no se utilicen procedimientos almacenados para la lógica empresarial. Esta separación es igualmente posible:

Capa de presentación: .Net, PHP, lo que sea

Capa de negocios: procedimientos almacenados

Capa de datos: procedimientos almacenados o DML

Esto funciona muy bien con Oracle, por ejemplo, donde la capa de negocios puede implementarse en paquetes en un esquema diferente al de la capa de datos (para imponer la separación adecuada de las preocupaciones).

Lo que importa es la separación de las preocupaciones, no el lenguaje / tecnología utilizada en cada nivel.

(¡Espero ser completamente flameado por esta herejía!)

Realmente depende de los requisitos. De cualquier manera, siempre y cuando NO esté "detrás del botón". Creo que los procedimientos almacenados son mejores para las aplicaciones de servidor de cliente "clásicas" con necesidades cambiantes. Una capa media "lógica de negocios" estricta es mejor para las aplicaciones que necesitan ser muy escalables, ejecutarse en múltiples plataformas de bases de datos, etc.

Sí, la lógica de negocios debe estar en la capa de lógica de negocios. Para mí, este es el mayor inconveniente de usar los procedimientos de la tienda para todo y, por lo tanto, mover algunas de las reglas comerciales a la base de datos. Prefiero tener esa lógica en el BLL para que la DLL solo se comunique con la base de datos.

SIEMPRE es una buena idea separar las capas. No puedo decirle la cantidad de veces que he visto procedimientos almacenados que son MUY extraños de mucha lógica de negocios escrita en el espacio. Además, si modifica su complejo procedimiento almacenado por cualquier motivo, tiene el potencial de romper TODO lo que lo usa.

Los desarrolladores de mi empresa se están mudando a LINQ w / the EF y están descartando el procedimiento almacenado a menos que lo necesitemos absolutamente. LINQ y el EF hacen que separar nuestras capas sea mucho más fácil ... cuando el EF no está siendo difícil. Pero eso es otra perorata. :)

Si está construyendo una arquitectura en capas, y la arquitectura contiene una capa de negocios dedicada, entonces, por supuesto, debe poner la lógica de negocios allí. Sin embargo, puede preguntar a cinco diseñadores / arquitectos / desarrolladores qué es realmente la "lógica empresarial" y obtener six answers different . (¡Eh, yo también soy arquitecto, así que sé todo sobre ''por un lado, pero por el otro''!). ¿Navegar por una parte del gráfico de objetos de la capa de datos o la capa de negocios? Depende de los patrones de EAA que esté utilizando y de qué tan complicados / inteligentes sean los objetos de su dominio. ¿O es quizás incluso parte de tu presentación?

Pero en términos más concretos: las herramientas de desarrollo de bases de datos tienden a quedarse atrás de Eclipse / Visual Studio / Netbeans /; y los procedimientos almacenados nunca han sido extremadamente cómodos para el desarrollo a gran escala. Sí, por supuesto, puede codificar todo en TSQL, PL / SQL & c, pero hay un precio que pagar. Además, el precio de tener varios idiomas y plataformas involucrados en una solución aumenta los costos de mantenimiento y los retrasos. Por otro lado, mover el acceso a los datos fuera del alcance de los DBA puede causar otros dolores de cabeza, especialmente en entornos de infraestructura compartida con cualquier tipo de requisitos de disponibilidad. Pero en general, sí, las herramientas y los idiomas modernos están moviendo la lógica desde la capa de datos (base) a la capa de aplicación. Tendremos que ver qué tan bien funciona y cómo se escala.

Si las aplicaciones son pequeñas con una vida útil corta, entonces no vale la pena dedicar tiempo a abstraer las preocupaciones en capas. En aplicaciones más grandes y de larga duración, su lógica / reglas de negocio no deben estar acopladas al acceso a los datos. Crea una pesadilla de mantenimiento a medida que crece la aplicación.

Mover las preocupaciones a una capa común o también conocida como Separación de preocupaciones , ha existido por un tiempo:

Wikipedia

El término separación de las preocupaciones probablemente fue acuñado por Edsger W. Dijkstra en su artículo de 1974 "Sobre el papel del pensamiento científico" 1 .

Para la arquitectura de aplicaciones, un gran libro para comenzar es el diseño impulsado por dominio . Eric Evans desglosa en detalle las diferentes capas de la aplicación. También analiza la impedancia de la base de datos y lo que él llama un "Contexto delimitado"

Contexto delimitado

Un blog es un sistema que muestra las publicaciones de la más reciente a la más antigua para que las personas puedan comentar. Algunos verían esto como un sistema, o un "Contexto delimitado". Si se suscribe a DDD, uno diría que hay dos sistemas o dos "Contextos delimitados" en un blog: un sistema de comentarios y un sistema de publicación. DDD sostiene que cada sistema es independiente (por supuesto, habrá interacción entre los dos) y debe modelarse como tal. DDD brinda orientación concreta sobre cómo separar las preocupaciones en las capas apropiadas.

Otros recursos que podrían interesarte:

Hasta que tuve la oportunidad de experimentar la gran bola de barro o el código de espagueti, me costó entender por qué la arquitectura de aplicaciones era tan importante ...

La forma correcta de hacer las cosas dependerá siempre del tamaño, los requisitos de disponibilidad y la vida útil de su aplicación. Para usar procs almacenados o no usar procs almacenados ... Las herramientas como nHibrnate y Linq to SQL son excelentes para proyectos pequeños o medianos. Para aclararme, nunca he usado nHibranate o Linq To Sql en una aplicación grande, pero mi intuición es que una aplicación alcanzará un tamaño en el que las optimizaciones se realizarán en el servidor de la base de datos a través de vistas, procedimientos almacenados, etc. para mantener el rendimiento de la aplicación. Para hacer este trabajo, se necesitarán desarrolladores con habilidades de desarrollo y de base de datos.

También hay razones / limitaciones técnicas que deben tenerse en cuenta al planificar dónde crear las reglas comerciales.

En la mayoría de las aplicaciones de LOB, la centralización y el rendimiento empujan a los desarrolladores a utilizar la base de datos como la principal capa de negocios, por lo que, en cierto sentido, DAL y BL se mezclan o unifican.

Un ejemplo típico sería el campo que calcula la ubicación actual de un elemento de alquiler, una información que debería estar disponible para uno o para muchos elementos listados, haciendo que una vista SQL con una función definida por el usuario sea el candidato más poderoso para mantener la regla .

El ejemplo anterior es válido, por supuesto, si se prefiere un diseño de base de datos específico y la implementación de procesos, pero solo quiero señalar que en el mundo real, elegimos en función de las limitaciones técnicas y otros principios, más a menudo de lo que lo hacemos para organizar nuestro código.