Nowy interfejs API parametrów generycznych rzeczywiście ma problem — powinien akceptować zwykłe null platformy .NET (a nie DBNull.Value ), otworzyłem ten problem
aby to śledzić, zostanie to naprawione w 4.0.3.
Pamiętaj, że jako notatka dotycząca dokumentacji
mówi, celem ogólnego API jest unikanie używania Value właściwość, która jest typu object . Jeśli używasz ogólnego NpgsqlParameter<int> ale przypisz Value , Twoje int zostanie zapakowane, co będzie niweczyć cel interfejsu API. Powinieneś przypisywać do TypedValue , który jest typu int i nie będzie boksować. Dlatego też nie możesz przypisać DBNull.Value aby wskazać wartość null (jest to inny typ .NET).
Kilka uwag na temat tego, czy ten nowy ogólny interfejs API powinien być używany:
- Jeśli piszesz wiele typów wartości (np.
int,DateTime...) spowoduje to usunięcie wszystkich przydziałów boksów. To, czy będzie to miało znaczenie, zależy od Twojej aplikacji - profiluj ostrożnie. - Ogólne interfejsy API powinny być zawsze preferowane w stosunku do nieogólnych, gdy typ jest znany w czasie kompilacji. Pozwala to kompilatorowi wcześnie sprawdzić poprawność typu i czyni kod bardziej przejrzystym - używamy
List<string>zamiastArrayListjako kwestia dobrego kodowania, nawet jeśli wydajność nie jest problemem - Główną (jedyną?) wadą ogólnego interfejsu API jest to, że jest on specyficzny dla Npgsql, dzięki czemu Twój kod nie może być przenoszony do innych sterowników baz danych (chociaż wystąpił problem za zrobienie tej (lub podobnej) części ADO.NET).
