La nouvelle API de paramètre générique a en effet un problème - elle devrait accepter le null .NET normal (et non DBNull.Value ), j'ai ouvert ce problème
pour suivre cela, il sera corrigé dans 4.0.3.
Notez que comme la note de documentation
dit, tout l'intérêt de l'API générique est d'éviter d'utiliser la Value propriété, qui est de type object . Si vous utilisez le générique NpgsqlParameter<int> mais attribuez Value , votre int sera mis en boîte, ce qui va à l'encontre de l'objectif de l'API. Vous devriez attribuer à TypedValue , qui est de type int et ne boxera pas. C'est aussi pourquoi vous ne pouvez pas attribuer DBNull.Value pour indiquer une valeur nulle (il s'agit d'un type .NET différent).
Quelques notes sur l'opportunité d'utiliser cette nouvelle API générique :
- Si vous écrivez de nombreux types de valeurs (par exemple,
int,DateTime...) cela supprimera toutes les allocations de boxe. Le fait que cela soit significatif dépend de votre application - profilez soigneusement. - Les API génériques en général doivent toujours être préférées aux API non génériques lorsque le type est connu au moment de la compilation. Cela permet au compilateur de vérifier l'exactitude du type tôt et rend votre code plus clair - nous utilisons
List<string>plutôt queArrayListcomme une question de bon codage même lorsque les performances ne sont pas un problème - Le principal (seul ?) inconvénient de l'API générique est qu'elle est spécifique à Npgsql, ce qui rend votre code non portable vers d'autres pilotes de base de données (bien que un problème existe pour avoir intégré ceci (ou quelque chose de similaire) à ADO.NET).
