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

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?

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.

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.

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.

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.

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.

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.