Quels sont les avantages d'un «Micro-ORM»?

21

J'ai étudié les soi-disant «Micro ORM» comme Dapper et (dans une moindre mesure car il repose sur .NET 4.0) Massif car ceux-ci pourraient être plus faciles à mettre en œuvre au travail qu'un ORM à part entière depuis notre système actuel est fortement tributaire des procédures stockées et nécessiterait une refactorisation importante pour fonctionner avec un ORM comme NHibernate ou EF. Quel est l'avantage d'utiliser l'un d'eux sur un ORM complet? Il semble que juste une couche mince autour d' une connexion de base de données que les forces fixes que vous écriviez SQL brute - peut - être que je me trompe , mais m'a toujours dit la raison de ORM en premier lieu est si vous n'avez à écrire SQL, il pourrait être généré automatiquement; en particulier pour les jointures multi-tables et les relations de mappage entre les tables, ce qui est difficile à faire en SQL pur mais trivial avec un ORM.

Par exemple, en regardant un exemple de Dapper:

var connection = new SqlConnection(); // setup here...
var person = connection.Query<Person>("select * from people where PersonId = @personId", new { PersonId = 42 });

En quoi est-ce différent de l'utilisation d'une couche de données ADO.NET contrôlée manuellement, sauf que vous n'avez pas à écrire la commande, définir les paramètres et je suppose que mapper l'entité à l'aide d'un générateur. Il semble que vous puissiez même utiliser un appel de procédure stockée comme chaîne SQL.

Y a-t-il d'autres avantages tangibles qui me manquent ici où un Micro ORM a du sens à utiliser? Je ne vois pas vraiment comment il enregistre quoi que ce soit par rapport à la "vieille" façon d'utiliser ADO.NET, sauf peut-être quelques lignes de code - vous devez encore écrire pour comprendre quel SQL vous devez exécuter (ce qui peut devenir poilu) et vous devez toujours mapper les relations entre les tables (la partie avec laquelle les ORM à mon humble avis aident le plus).

.net orm Wayne Molina
la source
+1: Vous aurez toujours besoin d'un langage de requête, quoi qu'il en soit, vous pouvez donc aussi vous en tenir à quelque chose de familier comme linq ou sql, mais le retour de types anonymes comme dans votre exemple ne semble pas mapper un modèle relationnel sur un domaine concret modèle. Cela me semble étrange.
Steven Evers
Ouais, je n'ai pas pu trouver d'exemple concret de Dapper, sur le site pour cela, il le fait littéralement var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });, puis dog.First().Agepour accéder aux propriétés.
Wayne Molina
5
L'exemple ne renvoie pas de type anonyme, le mot clé "var" peut être utilisé à la place d'un type concret en C # pour enregistrer le typage supplémentaire, cette requête retournerait IEnumerable <Person>.
Ed James
1
La raison principale est que les frais généraux sont réduits, il faut constamment archiver les sprocs, puis n'oubliez pas de mettre à jour environ deux douzaines de fichiers SQL, sans oublier d'avoir à stocker des procs pour du code CRUD trivial.
Wayne Molina
2
Le principal avantage de ne pas utiliser de sprocs pour conserver tout le code (et j'utilise le code à dessein ici, y compris SQL et vos autres langues de choix) dans le même système de contrôle de version. Je n'ai pas encore rencontré un bon VCS de base de données cross-DB.
Ed James

Réponses:

12

Avantages:

  • Performances similaires à une SqlCommand brute avec DataReader et l'analyse.
  • Pas besoin de rouler votre propre couche de conversion pour le DataReader.

C'est à peu près ça, pour être honnête. Vous avez un wrapper très léger pour vos connexions sql qui fera la conversion d'objet pour vous. Vous pouvez, bien entendu, affiner les requêtes sans avoir à traiter avec du SQL généré automatiquement.

Les inconvénients:

  • Pas même légèrement sécurisé. Si vous faites une faute de frappe dans le SQL, votre serveur CI ne va pas l'attraper, vous devrez espérer qu'il soit intercepté lors de l'interface utilisateur automatisée ou des tests fonctionnels.
  • Une douleur à entretenir. Vous avez un tas d'instructions SQL en ligne qui effectuent diverses requêtes qui n'ont pas de liens solides avec l'architecture de base de données. Cela peut très facilement conduire à des requêtes qui sont "laissées pour compte" lorsque la structure de la base de données sous-jacente change, ce que, encore une fois, vous ne verrez pas au moment de la génération.

Ils ont leur place, et ils sont un outil très efficace qui peut enlever une partie du "travail de l'âne" aux développeurs lorsqu'ils interagissent avec la base de données, mais en réalité, ils ne peuvent tout simplement pas prendre la place d'un ORM complet à grande échelle système pour les requêtes qui ne sont pas critiques en termes de performances, simplement en raison de l'augmentation des coûts de maintenance.

Si vous rencontrez des difficultés avec les performances sur les requêtes de base de données, je suggère qu'il serait préférable d'utiliser ces cadres de mappage avec les procédures stockées uniquement, afin d'obtenir une indication au moment de la compilation de la validité de votre SQL (plus les avantages de performances supplémentaires) .

Ed James
la source
Il existe des bibliothèques qui peuvent être utilisées comme wrapper pour ces micro-ormes, ce qui peut réduire le problème que vous mentionnez avec les fautes de frappe. Ex: Module complémentaire Simple Crud pour Dapper
Srivathsa Harish Venkataramana
3

Dans le site Web de micro ORM PetaPoco, il explique certains avantages avec d'autres ORM. pour expliquer plus

PetaPoco est un micro-ORM simple, rapide et à fichier unique pour .NET et Mono.

  • Comme Massive, c'est un seul fichier que vous ajoutez facilement à n'importe quel projet
  • Contrairement à Massive, il fonctionne avec des POCO fortement typés
  • Comme Massive, il prend désormais également en charge les Expandos dynamiques - en savoir plus
  • Comme ActiveRecord, il prend en charge une relation étroite entre l'objet et la table de base de données
  • Comme SubSonic, il prend en charge la génération de classes poco avec des modèles T4
  • Comme Dapper, il est rapide car il utilise la génération de méthode dynamique (MSIL) pour attribuer des valeurs de colonne aux propriétés
Christophe Debove
la source
1

En quoi est-ce différent de l'utilisation d'une couche de données ADO.NET contrôlée manuellement, sauf que vous n'avez pas à écrire la commande, définir les paramètres et je suppose que mapper l'entité à l'aide d'un générateur. Il semble que vous puissiez même utiliser un appel de procédure stockée comme chaîne SQL.

Je crois que c'est le principal avantage d'un Micro-ORM, pour obtenir les autres avantages d'un ORM dont vous auriez besoin pour en utiliser un à part entière. Cela et le code est relativement plus petit, donc si vous avez besoin de le personnaliser, ce serait plus facile.

Glace noir
la source