tło
We wczesnych latach .NET framework System.Data był ważnym elementem. Umożliwia tworzenie sterowników baz danych .NET, podobnie jak ActiveX Data Objects w Visual Basic. Chociaż API jest inne, jego nazwa jest używana ponownie, stąd przydomek ADO .NET.
Jedną z kluczowych różnic między ADO a ADO .NET (czyli System.Data) jest model obiektowy. W ADO zwykle wystarczy używać obiektów Connection, Command i Recordset, a sterownik OleDB/ODBC ukrywa coś innego. To poprawia ponowne wykorzystanie kodu, ale deweloperom trudno jest udostępnić niektóre funkcje bazy danych.
W ADO .NET możesz też używać OleDB/ODBC, ale w większości przypadków używasz serii klas specyficznych dla bazy danych. Klasy te pochodzą z DBConnection, DBCommand i DBDataReader, które zachowują możliwość ponownego użytku oryginalnego kodu. Ale ponieważ są to typy silnie nazwane, muszą być wyraźnie częścią biblioteki .NET.
Prawdopodobnie dla uproszczenia programowania, sterowniki SQL Server, OleDB i ODBC są częścią frameworka System.Data. To podejście było wówczas akceptowalne, ale powodowało problemy z obecnym cyklem rozwoju SQL Server.
W rzeczywistości cykle wydawań SQL Server zmieniały się z 3 do 5 lat do niemal każdego roku. Nowe wydania często wymagają aktualizacji sterownika .NET, co nie jest możliwe, jeśli jest powiązany z cyklem wydania standardu .NET.
Pierwszym krokiem jest podzielenie biblioteki System.Data. NET Core realizuje ten etap, udostępniając oddzielne biblioteki dla każdego sterownika bazy danych. Kolejnym krokiem jest całkowite oddzielenie sterownika SQL Server od .NET Core/Standard. Aby to zrobić, stworzyli Microsoft.Data.SqlClient.
Aktualizacja do Microsoft.Data.SqlClient
Dla większości programistów korzystanie z Microsoft.Data.SqlClient będzie bardzo proste, wystarczy zmodyfikować instrukcję using na górze każdej klasy. Dodatkowo używa tych samych nazw klas i API oraz oferuje mniej więcej te same funkcje.
Dla lekkich ORM, takich jak Dapper czy RepoDB, nie są wymagane dalsze zmiany.
Jeśli deweloperzy używają ORM do zarządzania połączeniami (np. EF, NHibernate), muszą poczekać na aktualizacje ORM.
Bardziej problematyczne są te, które mieszają ORM. Jeśli jeden ORM używa Microsoft.Data.SqlClient, a drugi System.Data.SqlClient, to nie będzie działać jednocześnie. Jest to szczególnie ważne przy pracy z obiektami współdzielonymi SqlTransaction.
Użyteczność
Wersja 1.0 Microsoft.Data.SqlClient jest dostępna na następujących platformach:
- .NET Framework 4.6+
- .NET Core 2.1+
- .NET Standard 2.0+
Znane problemy
Nie każdy musi od razu wymieniać sprzęt. Te znane problemy zostały odnotowane w dokumentacji:
- Typ danych użytkownika (UDT) może nie działać z Microsoft.Data.SqlClient.
- Azure Key Vault i Microsoft.Data.SqlClient nie mają magazynu kluczy.
- Microsoft.Data.SqlClient nie obsługuje Always Encrypted dla bezpiecznych enklaw.
- Tylko .NET Framework i .NET Core obsługują Always Encrypted, .NET Standard nie, ponieważ .NET Standard nie posiada niektórych zależności szyfrowania.
Oryginalny link:https://blog.csdn.net/weixin_39777464/article/details/111698467 |
Opublikowano 27.12.2021 22:21:14
|
|
|
