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

14

Al leer sobre buenas prácticas para aplicaciones de base de datos, con frecuencia me he encontrado con defensores de las llamadas "capas lógicas 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 lo que el DAL no puede manejar (ejecutar consultas y mapear resultados a objetos), por lo que mi BLL solo llama al DAL sin hacer nada por sí mismo.

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

    
pregunta Andrew Arnold 04.02.2011 - 22:28

6 respuestas

10

Para mis aplicaciones más pequeñas, mi BLL generalmente comienza como un paso al DAL. Estoy bien con eso. Cuando "descubro" las reglas comerciales, el BLL es donde las coloco. También termino encontrando muchas cosas necesarias en el BLL mientras escribo mis pruebas. Para mis propias aplicaciones personales, invento las reglas comerciales y el BLL todavía está donde las coloco. Para mí, el BLL es algo que crece con el tiempo. Cuanto más tiempo he trabajado en un proyecto, mayor es su BLL.

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

respondido por el Marcie 04.02.2011 - 22:51
5

El BLL manejaría cosas que son parte del dominio de negocios, no una parte de la base de datos, y no una parte de la UI (generalmente) Por ejemplo, usar la edad de un cliente para determinar si califica para un descuento especial para adultos mayores. El DAL no debería hacer esto, simplemente debería recuperar los datos del cliente y luego almacenarlos con los datos de descuento una vez 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.

    
respondido por el FrustratedWithFormsDesigner 04.02.2011 - 22:35
5

Andrew,

Capas de lógica de negocios es lo que terminas cuando haces un desarrollo impulsado por el dominio y te concentras en las actividades principales 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 transferirla fácilmente a otros usos, como dispositivos web o dispositivos móviles. Es una forma limpia de pensar en el desarrollo y, por lo que he visto, no se toma todo eso en serio, lamentablemente.

Recomiendo tener en sus manos Eric Evans - Domain Driven Design, que es un buen libro que justifica enfocar los esfuerzos de desarrollo en el dominio. Es cierto que es una lectura seca a mitad de camino, pero acumula ímpetu y tiene algunas convicciones sólidas en cuanto a lo que los desarrolladores están haciendo mal con los sistemas de hoy.

    
respondido por el Desolate Planet 05.02.2011 - 00:21
4

No hay nada que diga que TIENE QUE tener un cierto número de niveles o capas. Todo depende de la complejidad de tu proyecto. Eche un vistazo a muchas de las aplicaciones de muestra de MVC, como la cena nerd o la tienda de discos ... todas usan 2 capas porque para las 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 de abstraer 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 en toda la capa de presentación.

Suponga que decide cambiar su ORM de Linq a SQL a Entity Framework (o nhibernate). Probablemente será más fácil cambiarlo en la capa de negocios que en la capa de presentación, ya que la presentación tiende a ser muy parecida 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 la capa de negocios es el controlador.

    
respondido por el Erik Funkenbusch 04.02.2011 - 22:48
4

Complementando Desolate la respuesta del planeta sobre diseño impulsado por dominio:

Echa un vistazo también a The Onion Architecture , que está muy alineado con el diseño basado en dominio. conceptos.

Observe que la "capa" de Business Logic es el núcleo de la cebolla y que todas las capas de infraestructura (como la capa de acceso a datos) son sus dependencias externas. Esto ayuda a probar mucho, ya que debería poder simular cada dependencia de infraestructura externa y probar completamente la lógica de su 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, es posible que algunas aplicaciones no necesiten este tipo de arquitectura. Si todas sus aplicaciones son operaciones de CRUD con el conjunto 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 bases de datos. En ese caso, probablemente debería ser mejor que se centre solo en las capas DAL y UI.

    
respondido por el Sergio Acosta 05.02.2011 - 01:31
1

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

Piense en ello como en su capa de presentación: es bastante común pensar en cambiar la GUI por una 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 quizás por algo muy similar (por ejemplo, una base de datos SQLServer reemplazada con una MySQL), pero si imagina que tuvo que cambiar su base de datos a un almacenamiento distribuido servicio al que se accedió mediante una API, puede obtener una idea más clara de dónde se encuentran las capas.

    
respondido por el gbjbaanb 14.04.2011 - 18:17

Lea otras preguntas en las etiquetas