¿Vale la pena escribir un grupo de 2 funciones lineales en un objeto BLL solo para redirigir a DAL?

Question

Me parece bastante tonto. ¿Qué no obtengo?

Answer 1

Me he encontrado con casos como este en los que mi aplicación llama a una capa empresarial para seleccionar una lista de valores. La capa empresarial luego llama a Dal para hacer el acceso a los datos. En muchos de estos casos, no existe una razón aparente para el método de la capa empresarial que hace la transferencia, pero sí deja espacio para agregar lógica empresarial, procesamiento de datos, etc. en el futuro. También ayuda a mantener su aplicación desacoplada, lo que facilitará mucho las pruebas.

Por lo tanto, le digo que guarde las líneas, pero si sus inserciones, actualizaciones, etc. siguen siendo una o dos líneas, debe volver a pensar dónde está haciendo su validación y el procesamiento de datos a nivel comercial.

Answer 2

Si su BLL nunca valida o implementa ninguna lógica de negocios y siempre sigue siendo 2 líneas, entonces sí, es bastante tonto. Sin embargo, si hace esto, probablemente haya perdido el punto de tener una capa de lógica de negocios y probablemente haya estado haciendo su validación en la IU, o agregando lógica de negocios en su UI o su DAL. Hay muy pocas aplicaciones que no requieren validación y no tienen lógica empresarial.

Answer 3

Si bien Rob y Bullines a menudo tienen razón en que la necesidad de hacer esto apunta a un problema más profundo, hay casos legítimos en los que ir directamente a la capa de acceso a datos tiene mucho sentido. Escribir un método sin cerebro (o peor, modelo de objeto completo) para envolver la capa de acceso a datos es una de las cosas menos útiles que cualquier programador puede hacer, así que no lo hagas. Puede sentirse bien por no pasar por la capa de lógica de negocios si hay una razón legítima.

Answer 4

La lógica de negocios debe estar en su BLL. Si termina con "2 funciones de revestimiento" en su BLL, ¿colocó accidentalmente esa lógica de negocios en su DAL o UI?