Est-il préférable d’éviter le SQL inline avec dapper?

dapper

Question

J'ai envisagé d'utiliser dapper , mais je n'aime toujours pas l'idée d'utiliser SQL en ligne. Existe-t-il des idées sur stored procedures uniquement? Dans le cas où il y aurait un problème avec la requête, il ne serait pas nécessaire de la recompilation , mais simplement de modifier une stored procedure dans une base de données. Existe-t-il des alternatives telles que conserver toutes SQL queries dans sa propre bibliothèque de classes?

Réponse acceptée

Dapper prend en charge les deux options et n'a aucune opinion sur le sujet.

Votre question suggère que le déploiement de votre base de code est délicat. S'il s'agit d'un code côté client, cela peut être logique. Pour le code côté serveur, il est généralement plus facile de redéployer l’application que de modifier une procédure stockée - idéalement 1 clic via quelque chose comme TeamCity. Bien entendu, vos procédures stockées doivent également avoir un contrôle de processus / déploiement.

Avoir le SQL dans une bibliothèque de classes ne vous achètera pas grand chose: vous devez toujours le redéployer pour obtenir les modifications. Bien sûr, il peut être judicieux d’avoir votre code orienté données dans des assemblys séparés du code UI (etc), mais il s’agit d’une décision d’architecture locale.



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