Business Layer vs SQL Server

Question

Tengo una aplicación que hace cálculos complejos para los miembros. Cada miembro puede tener varios estados de EE. UU. Vinculados a su perfil. Cada estado tiene cálculos diferentes para cada curso que completa un miembro.

A partir de ahora he estado realizando los cálculos en la base de datos (SQL Server 2008) y luego envío los datos a la capa de aplicaciones donde pueden ver su historial y luego descargo un certificado para cada curso.

Tengo una capa de lógica de negocios, pero no sucede mucho allí. Sé que esto se ha preguntado mucho, pero ¿dónde crees que debería realizar estos cálculos: capa de negocios o base de datos? Voy a ir y venir !!

Answer 1

Me básicamente hacer nada en SQL Server que:

• hace un montón de sumar, contar, etc. promedio de los datos y devuelve un solo valor. No tiene sentido transferir grandes volúmenes de datos al nivel medio, solo para resumir una columna

• realiza una gran cantidad de manipulación basada en filas/conjuntos; si necesita copiar, insertar, actualizar muchos datos, una vez más, no tiene sentido arrastrar todos esos datos al nivel intermedio y luego enviarlos de vuelta al servidor; hágalo en el servidor desde el principio. También: T-SQL es significativamente más rápida a las operaciones basadas en conjuntos (como arrastrando los datos en todo) que cualquier otra cosa en su nivel medio podría ser

En resumen: tratar de evitar el envío de grandes volúmenes de datos al cliente/middle-tier/business layer a menos que sea absolutamente necesario (por ejemplo, porque desea descargar un archivo almacenado en una base de datos, o si realmente necesita para tener esas 200 filas materializadas en objetos en su aplicación para mostrar en algún lugar u operar en)

Una característica que a menudo se pasa por alto son columnas calculadas directamente en su tabla de la base de datos - aquellos son realmente buenos, por ej. resumiendo el total de su pedido más impuestos y envío en un total general, o son geniales para armar su nombre y apellido en un nombre para mostrar. Ese tipo de cosas realmente no deberían manejarse solo en la capa de lógica de negocios; si las hace directamente en la base de datos, esos valores "computados" también estarán disponibles cuando inspeccione las tablas de la base de datos y observe los datos en SQL Server. MGMT Estudio ...

---

yo lo pondría en la capa de lógica de nivel medio/negocio

• si se requiere un control exhaustivo de la lógica, análisis de cadenas, coincidencia de patrones y así sucesivamente; T-SQL chupa en esas cosas

• si se requiere cosas como llamar a un servicio web para obtener algunos datos para validar sus datos contra, o algo por el estilo

• si se requiere más de una operación lógica de negocio (en lugar de "estrictas operaciones atómicas" base de datos)

Pero esos son sólo directrices "ásperos" - que siempre es una decisión de diseño para cada caso, y yo no creo en reglas estrictas; su kilometraje puede variar, de un caso a otro, así que elija el enfoque que mejor funcione para cada tarea en cuestión.

Answer 2

Ayuda no tener código de lógica de negocios dentro de la base de datos (procedimientos almacenados). Es mucho mejor tenerlo directamente en la aplicación para que encaje en la arquitectura. Este código SQL contiene su lógica comercial y no tiene nada de malo. (Sin embargo, no hay nada de malo en tener datos o código relacionado con el mantenimiento en sprocs).

Si su capa de lógica de negocios no está haciendo demasiado y solo está pasando los datos de SQL Server a la persona que llama, tal vez no los necesite en absoluto.

Answer 3

La capa de lógica de negocios no está allí para hacer el trabajo pesado, su propósito es proporcionar una abstracción con entidades en el idioma del tema. Por lo tanto, la capa de negocios se puede usar para proporcionar un enfoque compartido y consistente para todas las capas/aplicaciones que se requieren para trabajar en ese espacio.

Para sobre-diseñar las cosas para hacer un punto, el objetivo final sería que la capa de lógica de negocios se use en una organización para todas las aplicaciones que trabajan en ese espacio temático. Es decir. envuelto en un servicio, etc.

En el mundo real de las pequeñas aplicaciones para hacer esto o aquello, la capa de lógica de negocios se siente como un apéndice en algunas ocasiones. El truco también es recordar que los casos de uso deben implementarse como pruebas en la capa de negocios, lo que le brinda otra forma de pensar cómo debería ser la interfaz pública.

La forma en que la capa de lógica de negocios realiza su trabajo debe ocultarse en las partes de la aplicación que la invocan.

Por lo tanto, es perfectamente aceptable calcular los datos de la manera más eficiente (es decir, sql), siempre que estos cálculos tengan una representación adecuada en la capa de lógica de negocios.