Dapper en relación con el diseño n-Tier (BLL / DAL)

bll business-logic-layer dapper data-access-layer

Pregunta

Tengo una pregunta lógica básica sobre Dapper.

Al intentar hacer las mejores prácticas de diseño, ¿Dapper difumina la línea entre DAL y BLL? Muchas recomendaciones son que el DAL no debe saber nada sobre el BLL y que el DAL solo debe devolver una cantidad de datos que el BLL debería convertir en algún objeto útil.

Me gustaría obtener la opinión de algunos de los expertos aquí sobre dónde se ajusta Dapper.

Es un gran proyecto y funciona muy bien, pero parece estar estrechamente relacionado con el BLL. Personalmente, no me opongo al enfoque, pero me pregunto si 1) hay una mejor manera de desacoplar Dapper y BLL, o 2) si no es un problema real, ya que no planeamos alejarnos de MS SQL.

Gracias.

EDIT: en respuesta al comentario de Marc:

Dapper es un gran producto y no se trata de un golpe de ninguna manera ... Lo que quiero decir con el BLL es que cuando ejecutas una consulta, comúnmente devuelve una colección de un tipo específico.

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

En este caso, la consulta devolverá una colección de Dog.

Si se implementó Dapper en la capa DAL, debería tener una referencia a la capa BLL para conocer los tipos de objetos que va a devolver.

Muchas recomendaciones son que el DAL nunca debe saber nada sobre el BLL. Solo estoy tratando de evaluar las mejores prácticas para implementar Dapper y mantener una buena estructura de diseño de N-Tier.

Sé que es algo subjetivo, pero si es lo suficientemente bueno para alimentar Stack Overflow, entonces todos deben haber descubierto la mejor manera de implementarlo en un entorno bien diseñado.

EDITAR: Notó que el tipo de "Perro" no se mostró en el ejemplo de consulta debido a los símbolos HTML.

EDIT de nuevo en respuesta a los comentarios de Hogan: El corazón de mi pregunta está más relacionado con la idea de que la línea de código anterior estaría en el DAL. Para mayor claridad, podemos suponer que tenemos una solución con el DAL y el BLL como proyectos de clase separados. Ahora, cuando esta línea de código entra en el proyecto DAL, el DAL tendrá que hacer referencia al BLL para obtener el objeto "Perro". ¿Está bien esta dependencia cruzada? o simplemente la forma en que el Dapper se usa más comúnmente? ¿O es una mala práctica y simplemente no es la mejor manera de usar Dapper? Sé que muchos "puristas" dirían que el DAL no debería saber nada sobre el BLL ... confiar en el objeto "Perro" en la línea de arriba violaría ese principio. Sin embargo, la línea anterior parece ser el uso de ejemplo más común de Dapper.

Respuesta aceptada

Piense en Dapper como un Rack para bases de datos, lea: http://samsaffron.com/archive/2012/01/16/that-annoying-insert-problem-getting-data-into-the-db-using-dapper

Dapper no te obligará a usar repositorios o patrones particulares.

No va a decirle dónde poner su lógica comercial. Si quiere complicar la lógica de su negocio con su código de acceso a datos, que así sea. Si no lo haces, no lo hagas. Dapper es agnóstico. Es una tecnología simple de acceso a datos.


Respuesta popular

Creo que tu pregunta está ignorando el contexto. DAL y BLL a menudo son sobre el contexto. No se trata de una sola línea de código (como lo sugiere su pregunta) sino de la clase, el espacio de nombres e incluso la ruta en un proyecto al archivo fuente con el código de línea. Muchas veces estos problemas son ignorados por los programadores que desean escribir un buen DAL y BLL y piensan que si usan la herramienta correcta, el problema se resuelve instantáneamente.

Permítanme darles algunos ejemplos basados ​​en la línea de código que proporcionó anteriormente para aclarar mi punto.

Si estuviera leyendo el código fuente de un proyecto y encontrara esa línea de código en un archivo * .aspx.cs, estaría un poco angustiado. El proyecto no es n-tier o modular.

Por el contrario, si estaba leyendo la fuente y encontré esa línea de código en un archivo llamado dog.cs en el subdirectorio DAL de un proyecto, estaría claro que este código pretende actuar como acceso a datos para objetos dog en la solución.

Se puede llegar a una conclusión similar si se encuentra en una llamada de directorio BLL.

No dejes de entender mi punto: no sugiero que tengas que tener un nombre de directorio DAL y BLL en tu solución. Solo digo que lo que define estos elementos es externo a una sección de código que realiza acceso a los datos. . Dicha línea de código podría contribuir a un sistema de n niveles muy bien diseñado o restarle valor.



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow