Den nye generiske parameter API har faktisk et problem - den burde acceptere almindelig .NET null (og ikke DBNull.Value ), jeg har åbnet dette problem
for at spore dette, vil det blive rettet i 4.0.3.
Bemærk, at som dokumentationsnotatet
siger, at hele pointen med den generiske API er at undgå at bruge Value egenskab, som er af typen object . Hvis du bruger den generiske NpgsqlParameter<int> men tildel Value , vil din int blive indrammet, hvilket besejrer formålet med API'en. Du bør tildele til TypedValue , som er af typen int og vil ikke bokse. Det er også derfor, du ikke kan tildele DBNull.Value for at angive en nulværdi (det er en anden .NET-type).
Nogle bemærkninger om, hvorvidt denne nye generiske API skal bruges:
- Hvis du skriver mange værdityper (f.eks.
int,DateTime...) dette vil fjerne alle boksetildelinger. Hvorvidt dette får betydning, afhænger af din ansøgning – profiler omhyggeligt. - Generiske API'er generelt bør altid foretrækkes frem for ikke-generiske, når typen er kendt på kompileringstidspunktet. Dette gør det muligt for compileren at tjekke typekorrektheden tidligt og gør din kode klarere - vi bruger
List<string>i stedet forArrayListsom et spørgsmål om god kodning, selv når ydeevnen ikke er et problem - Den største (eneste?) ulempe ved den generiske API er, at den er Npgsql-specifik, hvilket gør din kode ikke-portabel til andre databasedrivere (selvom der er et problem for at gøre dette (eller noget lignende) til en del af ADO.NET).