usando dapper per sostituire un OR/M completo

Question

Sono davvero impressionato da Dapper micro OR/M, mi piacerebbe davvero usarlo come compagno affiancato di alcuni OR/M a pieno titolo, e il mio essere evanescente al posto di esso. Non ho capito comunque se c'è qualche strategia per deserializzare una gerarchia da db: per esempio l'oggetto restituito per una riga recordset dipenderebbe da un campo (il cosiddetto 'discriminator' in NH per esempio). Inoltre la gerarchia può dividere più tabelle tramite un join, quindi il tipo che rappresenta la riga dipenderà dall'esistenza del record nell'altra tabella. Avere una gerarchia rappresentata da una combinazione delle due strategie di cui sopra sarebbe qualcosa che NH, ad esempio, non supporta, ma che esiste nella "vita relazionale". Quindi le domande:

• Dapper gestisce un simile scenario?
• questo scenario cancella gli sforzi di Dapper in termini di prestazioni?

Un altro argomento è il caching. La cache di Dapper per le query è un po 'troppo aggressiva, non sarebbe meglio avere un "contesto simile a una sessione" e avere una cache di query per ogni sessione, o questo offenderebbe nuovamente le principali motivazioni di Dapper?

Answer 1

Al momento Dapper non supporta logica di costruzione su misura, credo che quello che stai chiedendo è qualcosa di simile:

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); 

Abbiamo deciso contro attuare tale causa logica non abbiamo mai avuto realmente a risolvere un problema come questo nella vita reale. Introduce anche una buona dose di complessità interna e una buona dose di complessità esterna (dato che è necessario attivare post is Question).

Non sono categoricamente contrario a includere questo tipo di funzionalità se si può fare una buona argomentazione per l'inclusione e la patch è semplice. Sono anche tutti per aggiungere ganci a Dapper per permetterti di iniettare questo tipo di funzionalità.

Per quanto riguarda la strategia di memorizzazione nella cache, scopriamo che in generale non abbiamo mai gonfiato la cache, il gonfiore si verifica solo se si utilizza abusivamente dapper, per esempio, generando un SQL non parametrizzato. Sostengo totalmente l'aggiunta di un hook che consente di specificare il proprio provider di cache invece dello ConcurrentDictionary utilizzato ora.