¿Para qué sirve una capa de lógica de negocios (BLL)?

14

Al leer sobre buenas prácticas para aplicaciones de bases de datos, con frecuencia me encuentro con defensores de las llamadas "capas de lógica de negocios" y estoy tratando de decidir si es mejor para mi proyecto usar una (es un pequeño proyecto personal). Mi problema radica en el hecho de que no puedo pensar en nada para que el BLL haga que el DAL ya no pueda manejar (ejecutar consultas y asignar resultados a objetos), por lo que mi BLL simplemente llama al DAL sin hacer nada por sí mismo.

Tal vez me equivoque sobre lo que el DAL debería estar haciendo también. Pero independientemente, ¿qué tipo de funcionalidad debería esperarse de un BLL en una aplicación de administración de bases de datos?

Andrew Arnold
fuente
Suena como eficiencia vs flexibilidad / dilema de reutilización de código.
Trabajo
@ Job - Sí, más o menos, especialmente porque es una aplicación pequeña con pocas posibilidades de reutilización de código (todavía). Pero también está tratando en parte de utilizar la mejor práctica posible.
Andrew Arnold
Voté a todos porque todos son excelentes respuestas; desafortunadamente solo puedo aceptar uno.
Andrew Arnold

Respuestas:

10

Para mis aplicaciones más pequeñas, mi BLL generalmente comienza como una transferencia al DAL. Estoy de acuerdo con eso. A medida que "descubro" las reglas comerciales, el BLL es donde las pongo. También termino encontrando muchas cosas necesarias en el BLL mientras escribo mis pruebas. Para mis propias aplicaciones personales, invento las reglas de negocio, y el BLL todavía está donde las puse. Para mí, el BLL es algo que crece con el tiempo. Cuanto más tiempo trabaje en un proyecto, mayor será su BLL.

¿Consideraría combinar BLL y DAL para un proyecto pequeño? Podría, excepto por el hecho de que cambio las tecnologías DAL con tanta frecuencia como cambio los peinados, y me gusta tener algo para aislar mi código de cliente de eso.

Marcie
fuente
2
No he cambiado mi peinado en 20 años. Odiaría cambiar mi tecnología DAL tan a menudo como cambio los peinados.
Erik Funkenbusch
3
¡Algunas personas solo actualizan su DAL cada 20 años también!
Marcie
44
Buena respuesta. Es común que los proyectos pequeños realmente no tengan mucho que poner en el BLL. También es común que los proyectos pequeños crezcan, y si no tuviera al menos un caparazón de BLL en su lugar, la creciente cantidad de lógica se acumulará en la capa de presentación o en el DAL, ninguno de los cuales es particularmente deseable.
Carson63000
5

El BLL manejaría cosas que son parte del dominio comercial, no una parte de la base de datos y no una parte de la IU (generalmente). Por ejemplo, usar la edad de un cliente para determinar si califica para un descuento especial para personas mayores. El DAL no debería estar haciendo esto, simplemente debería recuperar los datos del cliente y luego almacenarlos con los datos de descuento después de que el BLL haya hecho su trabajo. El DAL debería centrarse más en CRUD. En aplicaciones pequeñas, las dos preocupaciones pueden superponerse.

FrustratedWithFormsDesigner
fuente
En realidad, esto es parte del problema al tratar de aislar "niveles" o "capas" como este. Muchas veces, algo tiene que cruzar capas porque es más adecuado en esa capa diferente. Un gran ejemplo son las consultas SQL que tienen lógica empresarial incorporada. Su cálculo de edad, por ejemplo, podría hacerse completamente en la capa SQL (o ORM) de manera más eficiente.
Erik Funkenbusch
2
@Mystere Man Más eficientemente es subjetivo. Ese comentario significa que sabes lo que está sucediendo en el front-end. Es muy estático en la naturaleza. Utilice las consultas SQL para optimizar los datos con seguridad, pero hay una línea muy fina a medida que comienza a vincular una interfaz de usuario en el back-end.
Aaron McIver
1
@Mystere Man: De hecho, puede. Y a menudo es cierto que las cosas "sangran" de una capa a otra. El verdadero arte está en separarlos y mantenerlos separados. Lo sé, no siempre es fácil ...
FrustratedWithFormsDesigner
1
¡Y boom , la optimización prematura levanta su cabeza fea! Me resulta difícil imaginar que una simple comparación de fechas sea un cuello de botella que justifique trasladar una regla comercial al DAL. La mantenibilidad también debe ser un objetivo, no solo la velocidad.
TMN
5

Andrés,

Las capas de lógica de negocios es con lo que termina cuando realiza un desarrollo impulsado por el dominio y se enfoca en las actividades centrales del dominio. Si elimina la capa de presentación (gui, web) y la capa de infraestructura (db, conectividad de red, etc.), tiene las actividades principales que forman parte de su dominio, como depositar dinero en una cuenta bancaria. Ahora, si ha modelado su capa empresarial y la ha aislado de la presentación y la infraestructura, puede trasladarla fácilmente a otros usos, como la web o dispositivos móviles. Es una forma limpia de pensar sobre el desarrollo y, por lo que he visto, desafortunadamente no se lo ha tomado tan en serio.

Recomiendo poner sus manos en Eric Evans - Diseño impulsado por dominio, que es un buen libro que justifica centrar los esfuerzos de desarrollo en el dominio. Es cierto que es una lectura un poco seca a mitad de camino, pero genera impulso y tiene algunas fuertes convicciones sobre lo que los desarrolladores están haciendo mal con los sistemas actuales.

Planeta desolado
fuente
4

No hay nada que diga que TIENES que tener un cierto número de niveles o capas. Todo depende de la complejidad de su proyecto. Eche un vistazo a muchas de las aplicaciones de muestra MVC, como nerd dinner o record store ... todas usan 2 capas porque para aplicaciones que tienen muy poca lógica de procesamiento, simplemente no tiene sentido.

Sin embargo, incluso si su aplicación es pequeña, podría beneficiarse abstrayendo la capa de datos de la capa de presentación a través de una tercera capa que normalmente sería una capa de negocios. Esto le permite realizar cambios en un solo lugar, en lugar de hacerlo en toda la capa de presentación.

Suponga que decide cambiar su ORM de Linq a SQL a Entity Framework (o nhibernate). Es probable que sea más fácil cambiarlo en la capa empresarial que en la capa de presentación, ya que la presentación tiende estrechamente a su modelo de presentación.

Si comprende MVC, es decir ... Model View Controller, puede pensar en la arquitectura de su aplicación en términos similares. El modelo es análogo a su capa de datos, la capa de presentación es la vista y Business Layer es el controlador.

Erik Funkenbusch
fuente
4

Complementando la respuesta de Desolate Planet sobre el diseño impulsado por dominio:

Consulte también The Onion Architecture , que está muy alineada con los conceptos de diseño impulsado por dominio.

Observe cómo la "capa" de Business Logic es el núcleo de la cebolla y cada capa de infraestructura (como la capa de acceso a datos) son sus dependencias externas. Esto ayuda a probar mucho, porque deberías poder burlarte de cada dependencia de infraestructura externa y probar completamente la lógica de tu dominio.

En mi opinión: la capa de lógica de negocios es donde vive la "solución conceptual pura". El resto son solo detalles de implementación de infraestructura.

Sin embargo, algunas aplicaciones pueden no necesitar este tipo de arquitectura. Si todas sus aplicaciones son operaciones CRUD de conjuntos de datos, su 'solución conceptual pura' podría estar prácticamente vacía y todo lo que necesita es un front-end de edición de base de datos. En ese caso, probablemente debería ser mejor enfocarse solo en las capas DAL y UI.

Sergio Acosta
fuente
1

La respuesta a esta pregunta es (en mi humilde opinión): "¿puedo reemplazar mi DAL por completo y no tener que volver a escribir ninguno de mis códigos de lógica de negocios"?

Piense en ello como su capa de presentación: es bastante común pensar en cambiar la GUI por otra diferente, una GUI de escritorio gruesa se intercambia por un cliente web, que se intercambia por una aplicación de iPhone. No es tan común pensar así para BLL / DAL, ya que nunca se intercambian realmente, excepto tal vez por algo muy similar (por ejemplo, una base de datos SQLServer reemplazada por una MySQL), pero si imagina que tuvo que cambiar su base de datos a un almacenamiento distribuido servicio al que se accedió utilizando una API, puede tener una idea más clara de dónde se encuentran las capas.

gbjbaanb
fuente