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

Cet article d'Adam Anderson décrit les différences entre plusieurs bibliothèques d'extension CRUD Dapper:

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

Différences d'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