Dapper.Rainbow VS Dapper.Contrib

dapper dapper-rainbow orm

Question

Quelqu'un peut-il s'il vous plaît expliquer la différence entre Dapper.Rainbow vs Dapper.Contrib ?

Je veux dire quand utilisez-vous SqlMapperExtensions.cs de Dapper.Contrib et quand devriez-vous utiliser Dapper.Rainbow?

Réponse acceptée

J'utilise Dapper depuis un moment déjà et je me suis demandé ce que les projets Contrib et Rainbow étaient tout à propos de moi. Après un peu de révision du code, voici mes réflexions sur leurs utilisations:

Dapper.Contrib

Contrib fournit un ensemble de méthodes d'extension sur l'interface IDbConnection pour les opérations CRUD de base:

  • Obtenir
  • Insérer
  • Mettre à jour
  • Effacer

Le composant clé de Contrib est le suivi des entités pour déterminer si des modifications ont été apportées.

Par exemple, l'utilisation de la méthode Get avec une interface en tant que contrainte de type renverra une classe proxy générée dynamiquement avec un dictionnaire interne pour suivre les propriétés qui ont été modifiées.

Vous pouvez ensuite utiliser la méthode Update qui générera le SQL nécessaire pour ne mettre à jour que les propriétés modifiées.

Avertissement majeur : pour obtenir la qualité de suivi de Contrib, vous devez utiliser une interface comme contrainte de type pour permettre la génération de la classe proxy.

Dapper.Rainbow

Rainbow est une classe abstraite que vous pouvez utiliser comme classe de base pour vos classes Dapper afin de fournir des opérations CRUD de base:

  • Obtenir
  • Insérer
  • Mettre à jour
  • Effacer

Ainsi que certaines méthodes couramment utilisées telles que First (obtient le premier enregistrement dans une table) et All (obtient tous les enregistrements de résultats dans une table).

À toutes fins utiles, Rainbow est fondamentalement un wrapper pour vos interactions de base de données les plus couramment utilisées et construira le SQL ennuyeux basé sur des noms de propriété et des contraintes de type.

Par exemple, avec une opération Get, Rainbow va créer une requête SQL complète et renvoyer toutes les colonnes, puis associer ces valeurs au type utilisé comme contrainte.

De même, les méthodes d'insertion / mise à jour généreront dynamiquement le SQL nécessaire pour une insertion / mise à jour basée sur les noms de propriété de la contrainte de type.

Avertissement majeur : Rainbow s'attend à ce que toutes vos tables aient une colonne d'identité nommée "Id".

Différences?

La principale différence entre Contrib et Rainbow est (IMO), l'une suit les modifications apportées à vos entités, l'autre non:

  • Utilisez Contrib pour pouvoir suivre les modifications dans vos entités.
  • Utilisez Rainbow lorsque vous souhaitez utiliser quelque chose de plus comme une approche standard ADO.NET.

Sur une note de côté: j'aurais aimé regarder Rainbow plus tôt car j'ai construit une classe de base très similaire à celle que j'utilise avec Dapper.


De l'article et de la citation, @anthonyv a cité: Ce problème INSERT ennuyeux, récupérer des données dans la base de données

Vous pouvez également choisir parmi 2 autres API (à part Rainbow ) (pour CRUD) Dapper.Contrib et Dapper Extensions . Je ne pense pas que taille unique. Selon votre problème et vos préférences, il peut exister une API qui vous convient le mieux. J'ai essayé de présenter certaines des options. Il n’ya pas de «bonne façon» de résoudre tous les problèmes du monde.

Je soupçonne que ce que Sam essayait de transmettre dans la citation ci-dessus et l'article de blog associé était: Votre scénario peut nécessiter beaucoup de mappage personnalisé (utilisez vanilla Dapper), ou il peut avoir besoin ont des scénarios d'utilisation courants (utilisez Rainbow) ou vous pouvez utiliser une combinaison de tous. Ou même pas utiliser Dapper. YMMV.


Réponse populaire

Ce post par Adam Anderson décrit les différences entre plusieurs bibliothèques d'extension CRUD Dapper:

  • Dapper Contrib (suivi automatique des modifications - uniquement s'il est sale ou non, attributs du mappage personnalisé, pas de prise en charge de clé composite, pas de prise en charge manuelle des clés)
  • Dapper Rainbow (suivi manuel des modifications à l'aide de Snapshotter, attributs pour un mappage personnalisé, pas de prise en charge de clé composite, pas de prise en charge manuelle des clés)
  • Extensions Dapper (pas de suivi des modifications, configuration courante pour le mappage personnalisé, prise en charge des clés composites, prise en charge de la spécification par clé manuelle), comprend également un système de prédicat pour les requêtes simples
  • Dapper SimpleCRUD (Pas de suivi des modifications, Attributs de mappage personnalisé, Pas de prise en charge de clé composite, Prise en charge de la spécification de clé manuelle), inclut également des aides de filtrage / pagination, prise en charge asynchrone, génération de classe POCO automatique (via T4)

Différences entre les extensions Dapper




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