usando dapper para reemplazar un OR / M completamente desarrollado

c# dapper orm

Pregunta

Estoy realmente impresionado por Dapper micro OR / M, realmente me gustaría usarlo como compañero de lado a lado de algún OR / M completamente desarrollado, y mi ser evantualmente en lugar de él. No resolví de todos modos si hay alguna estrategia para deserializar una jerarquía de db: por ejemplo, el objeto devuelto para una fila del conjunto de registros dependería de un campo (el llamado 'discriminador' en NH, por ejemplo). Además, la jerarquía puede dividir más tablas a través de una unión, por lo que el tipo que representa la fila dependerá de la existencia del registro en la otra tabla. Tener una jerarquía representada por una mezcla de las dos estrategias anteriores sería algo que NH, por ejemplo, no admite, pero que existe en la "vida relacional". Entonces las preguntas:

  • Cómo maneja Dapper tal escenario?
  • ¿este escenario quiere los esfuerzos de Dapper en términos de rendimiento?

Otro tema es el almacenamiento en caché. Dapper Cache para consultas es un poco agresivo, ¿no sería mejor tener una "sesión como contexto" y tener un caché de consultas para cada sesión, o esto ofendería las principales motivaciones de Dapper?

Respuesta aceptada

Por el momento Dapper no es compatible con la lógica de construcción personalizada, supongo que lo que está pidiendo es algo así como:

class Post {}
class Question : Post { .. }
class Answer : Post { ... }

Func<IDbDataReader, Func<IDbDataReader, Post>> factoryLocator
        = ... my magic factory locater; 

cnn.Query<Post>(@"
select * from Posts p 
left join Questions q on q.Id = p.Id 
left join Answers a on a.Id = p.Id", factoryLocator: factoryLocator);

Decidimos no implementar tal lógica porque nunca tuvimos que resolver realmente un problema como este en la vida real. También presenta una buena cantidad de complejidad interna y una buena cantidad de complejidad externa (ya que necesita activar la post is Question ).

No estoy categóricamente en contra de incluir este tipo de características si puede presentar un buen argumento para la inclusión y el parche es simple. También estoy a favor de agregar ganchos en Dapper para permitirle inyectar este tipo de funcionalidad.

En cuanto a la estrategia de almacenamiento en caché, encontramos que, en general, nunca abominamos la memoria caché, la distensión solo ocurre si malgastas a dapper digamos, generando SQL no parametrizado. Apoyo totalmente la adición de un enlace que le permita especificar su propio proveedor de memoria caché en lugar del ConcurrentDictionary usa ahora.



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