Die neue generische Parameter-API hat tatsächlich ein Problem – sie sollte reguläres .NET null akzeptieren (und nicht DBNull.Value ), habe ich diese Ausgabe
geöffnet Um dies zu verfolgen, wird es in 4.0.3 behoben.
Beachten Sie das als Dokumentationshinweis
sagt, der springende Punkt der generischen API ist es, die Verwendung des Value zu vermeiden -Eigenschaft, die vom Typ object ist . Wenn Sie den generischen NpgsqlParameter<int> verwenden aber Value zuweisen , wird Ihr int umrahmt, wodurch der Zweck der API zunichte gemacht wird. Sie sollten TypedValue zuweisen , die vom Typ int ist und wird nicht boxen. Aus diesem Grund können Sie DBNull.Value auch nicht zuweisen um einen Nullwert anzugeben (es handelt sich um einen anderen .NET-Typ).
Einige Hinweise, ob diese neue generische API verwendet werden sollte:
- Wenn Sie viele Werttypen schreiben (z. B.
int,DateTime...) Dadurch werden alle Boxzuweisungen entfernt. Ob dies von Bedeutung sein wird, hängt von Ihrer Anwendung ab - profilieren Sie sich sorgfältig. - Generische APIs sollten im Allgemeinen immer gegenüber nicht-generischen APIs bevorzugt werden, wenn der Typ zur Kompilierzeit bekannt ist. Dadurch kann der Compiler die Typkorrektheit frühzeitig prüfen und macht Ihren Code übersichtlicher – wir verwenden
List<string>stattArrayListals Frage der guten Codierung, auch wenn die Leistung keine Rolle spielt - Der größte (einzige?) Nachteil der generischen API ist, dass sie Npgsql-spezifisch ist, wodurch Ihr Code nicht auf andere Datenbanktreiber portierbar ist (obwohl es liegt ein Problem vor dafür, dass Sie dies (oder etwas Ähnliches) in ADO.NET integriert haben).
