C'est un peu une question ouverte, mais je voulais des opinions, car j'ai grandi dans un monde où les scripts SQL en ligne étaient la norme, puis nous avons tous été très conscients des problèmes liés à l'injection SQL et de la fragilité du SQL quand faire des manipulations de cordes partout.
Puis vint l'aube de l'ORM où vous expliquiez la requête à l'ORM et le laissiez générer son propre SQL, ce qui dans de nombreux cas n'était pas optimal mais était sûr et facile. Une autre bonne chose à propos des ORM ou des couches d'abstraction de base de données était que le SQL a été généré avec son moteur de base de données à l'esprit, donc je pouvais utiliser Hibernate / Nhibernate avec MSSQL, MYSQL et mon code n'a jamais changé, c'était juste un détail de configuration.
Maintenant, passons rapidement à la journée actuelle, où les Micro ORM semblent gagner plus de développeurs.Je me demandais pourquoi nous avions apparemment fait demi-tour sur l'ensemble du sujet SQL en ligne.
Je dois admettre que j'aime l'idée de ne pas avoir de fichiers de configuration ORM et de pouvoir écrire ma requête de manière plus optimale, mais j'ai l'impression de m'ouvrir aux anciennes vulnérabilités telles que l'injection SQL et je m'attache également à un moteur de base de données, donc si je veux que mon logiciel prenne en charge plusieurs moteurs de base de données, je devrais faire un peu plus de piratage de chaînes qui semble alors commencer à rendre le code illisible et plus fragile. (Juste avant que quelqu'un ne le mentionne, je sais que vous pouvez utiliser des arguments basés sur des paramètres avec la plupart des micro orms qui offrent une protection dans la plupart des cas contre l'injection SQL)
Alors, quelles sont les opinions des gens sur ce genre de chose? J'utilise Dapper comme Micro ORM dans ce cas et NHibernate comme ORM normal dans ce scénario, mais la plupart dans chaque domaine sont assez similaires.
Ce que j'appelle sql en ligneest des chaînes SQL dans le code source. Il y avait autrefois des débats sur la conception des chaînes SQL dans le code source, ce qui portait atteinte à l'intention fondamentale de la logique.C'est pourquoi les requêtes de style linq typées de manière statique sont devenues si populaires qu'il ne s'agit que d'un seul langage, mais avec disons C # et Sql sur une seule page, vous avez 2 langues entremêlées dans votre code source brut maintenant. Juste pour clarifier, l'injection SQL n'est qu'un des problèmes connus avec l'utilisation de chaînes sql, je mentionne déjà que vous pouvez empêcher cela de se produire avec des requêtes basées sur des paramètres, mais je souligne d'autres problèmes liés à l'intégration des requêtes SQL dans votre code source, telles que l'absence d'abstraction de fournisseur de base de données ainsi que la perte de tout niveau de capture d'erreur de temps de compilation sur les requêtes basées sur des chaînes, ce sont tous des problèmes que nous avons réussi à contourner avec l'aube des ORM avec leur fonctionnalité de requête de niveau supérieur,
Je suis donc moins concentré sur les problèmes individuels mis en évidence et de plus en plus, il devient maintenant plus acceptable d'avoir à nouveau des chaînes SQL directement dans votre code source, car la plupart des Micro ORM utilisent ce mécanisme.
Voici une question similaire qui a quelques points de vue différents, bien qu'elle concerne davantage le sql en ligne sans le contexte micro orm: