Dapper et varchars

dapper varchar

Question

J'ai trouvé le commentaire suivant sur la page d'accueil du projet Dapper .NET .

Dapper prend en charge les paramètres varchar, si vous exécutez une clause where sur une colonne varchar à l'aide d'un paramètre, veillez à le transmettre de la manière suivante:

    Query<Thing>("select * from Thing where Name = @Name", new {Name = 
    new DbString { Value = "abcde", IsFixedLength = true, Length = 10, IsAnsi = true });

Sur Sql Server, il est crucial d’utiliser l’unicode lorsqu’on interroge unicode et ansi lorsqu’on interroge unicode

J'évalue Dapper pour une utilisation avec une base de données héritée (SQL Server 2008), avec beaucoup de procédures stockées avec des paramètres varchar, et je suis un peu confus par cette restriction.

Avec le code ADO.NET fabriqué à la main, j'utiliserais ce qui suit pour la requête ci-dessus:

new SqlParameter("@Name", "abcde")

sans préciser si c'est unicode ou non, ni la longueur.

  • Pourquoi ai-je besoin de cette syntaxe DbString détaillée avec Dapper, en spécifiant la longueur de la colonne, IsFixedLength et IsAnsi?

  • Pourquoi IsFixedLength = true pour une colonne varchar (je m'attendrais à ce qu'elle soit vraie pour une colonne char ou nchar)?

  • Dois-je utiliser DbString comme ceci pour les paramètres de procédure stockée?

Je m'attendais à ce que Dapper rende mon code DAL plus concis, mais cela semble être plus bavard pour les paramètres de varchar.

METTRE À JOUR

J'ai cherché un peu plus loin, pour essayer de comprendre pourquoi Dapper aurait cette restriction varchar, que je ne semble pas avoir dans mon code fabriqué à la main, où je créerais normalement un paramètre d'entrée comme suit:

var parameter = factory.CreateParameter(); // Factory is a DbProviderFactory
parameter.Name = ...;
parameter.Value = ...;

et généralement laisser le fournisseur inférer le DbType utilisant ses propres règles, sauf si je veux spécifiquement le contraindre.

En regardant la classe DynamicParameters de Dapper, il a une méthode AddParameters qui crée des paramètres comme suit:

var dbType = param.DbType; // Get dbType and value
var val = param.Value;     // from 

...
// Coerce dbType to a non-null value if val is not null !!!!!
if (dbType == null && val != null) dbType = SqlMapper.LookupDbType(val.GetType(),name);
...
var p = command.CreateParameter();
...
if (dbType != null)                     
{                         
    p.DbType = dbType.Value;                     
}

Cela force explicitement IDataParameter.DbType à une valeur recherchée avec son propre algorithme, plutôt que de laisser le fournisseur utiliser ses propres règles.

Y a-t-il une bonne raison à cela? Cela me semble faux, en particulier à la lumière du commentaire sur le support de Dapper pour les paramètres varchar.

Réponse populaire

Vous avez besoin de cette syntaxe lorsque vous travaillez avec ODBC.

Vous devez définir un champ CHAR (30) en tant que DbString dans c # pour Dapper et définir également les valeurs length (30) et ansi (true) pour empêcher Dapper de supposer que la chaîne est de type text / blob. Sinon, vous recevrez probablement l'erreur: "Tentative illégale de conversion du type blob Texte / Byte".

Je recevais cette erreur en utilisant ODBC pour me connecter à Informix jusqu'à ce que je définisse mon paramètre en tant que DbString () et définisse la longueur et les valeurs d'ansi.

Plus d'infos ici .




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