utiliser dapper pour remplacer un OR / M à part entière

c# dapper orm

Question

Je suis vraiment impressionné par Dapper micro OR / M, je voudrais vraiment l'utiliser comme compagnon côte à côte de certains OR / M à part entière, et mon être à la place. Je n'ai pas compris de toute façon s'il y avait une stratégie pour désérialiser une hiérarchie à partir de db: par exemple, l'objet renvoyé pour une ligne de jeu d'enregistrements dépendrait d'un champ (le "discriminateur" dans NH par exemple). De plus, la hiérarchie peut diviser plus de table via une jointure, de sorte que le type qui représente la ligne dépendra de l'existence de l'enregistrement dans l'autre table. Avoir une hiérarchie représentée par un mélange des deux stratégies ci-dessus serait quelque chose que NH par exemple ne supporte pas, mais qui existe dans la «vie relationnelle». Donc, les questions:

  • Dapper gère-t-il un tel scénario?
  • Est-ce que ce scénario élimine les efforts de Dapper en termes de performance?

Un autre sujet concerne la mise en cache. Le cache Dapper pour les requêtes est un peu trop agressif, ne serait-il pas préférable d'avoir un "contexte de session" et un cache de requêtes pour chaque session, ou est-ce que cela choquerait les motivations principales de Dapper?

Réponse acceptée

À l'heure actuelle, Dapper ne prend pas en charge la logique de construction personnalisée. Je suppose que ce que vous demandez, c'est quelque chose comme:

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

Nous avons décidé de ne pas mettre en œuvre une telle logique car nous n'avons jamais eu à résoudre un problème comme celui-ci dans la vie réelle. Il introduit également une certaine complexité interne et une quantité considérable de complexité externe (comme vous avez besoin d'activer la post is Question ).

Je ne suis pas catégoriquement contre l'inclusion de ce genre de fonctionnalité si vous pouvez faire un bon argument pour l'inclusion et le patch est simple. Je suis aussi tout pour ajouter des hooks dans Dapper pour vous permettre d'injecter ce type de fonctionnalité.

En ce qui concerne la stratégie de mise en cache, nous constatons qu'en général, nous ne faisons jamais de saturation du cache, le gonflement ne se produit que si vous utilisez Dapper par exemple, en générant du SQL non paramétrable. Je soutiens totalement l'ajout d'un hook qui vous permettrait de spécifier votre propre fournisseur de cache au lieu du ConcurrentDictionary utilisé maintenant.




Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi