Lucrul cu tipuri de referinta anulabile – EF Core

• 09/09/2019
• 5 minute de citit

In acest articol

C # 8 a introdus o noua caracteristica numita tipuri de referinta nullable (NRT), care permite adnotarea tipurilor de referinta, indicand daca este valabil ca acestea sa contina nul sau nu. Daca sunteti nou la aceasta functie, este recomandat sa va familiarizati cu aceasta citind documentele C #.

Aceasta pagina introduce asistenta EF Core pentru tipurile de referinta nulabile si descrie cele mai bune practici pentru lucrul cu acestea.

Proprietati obligatorii si optionale

Documentatia principala privind proprietatile necesare si optionale si interactiunea acestora cu tipurile de referinta nulabile este pagina Proprietati obligatorii si optionale. Este recomandat sa incepeti citind mai intai acea pagina.

Proprietati care nu pot fi anulate si initializare

Cand sunt activate tipurile de referinta nulabile, compilatorul C # emite avertismente pentru orice proprietate neinvalabila neinitializata, deoarece acestea ar contine nul. Ca urmare, nu se poate utiliza urmatorul mod comun de scriere a tipurilor de entitati:

public class CustomerWithWarning {public int Id {get; a stabilit; } // Genereaza CS8618, proprietate non-nulabila neinitializata: sir public Name {get; a stabilit; }}

Legarea constructorului este o tehnica utila pentru a va asigura ca proprietatile dvs. care nu sunt anulabile sunt initializate:

public class CustomerWithConstructorBinding {public int Id {get; a stabilit; } public string Nume {get; a stabilit; } public CustomerWithConstructorBinding (nume sir) {Nume = nume; }}

Din pacate, in unele scenarii legarea constructorului nu este o optiune; proprietatile de navigare, de exemplu, nu pot fi initializate in acest fel.

Proprietatile de navigare necesare prezinta o dificultate suplimentara: desi un dependent va exista intotdeauna pentru un anumit principal, acesta poate sau nu sa fie incarcat de o anumita interogare, in functie de nevoile din acel moment al programului (consultati diferitele modele pentru incarcarea datelor) . In acelasi timp, nu este de dorit ca aceste proprietati sa fie anulate, deoarece acest lucru ar forta accesul la acestea pentru a verifica daca sunt nule, chiar daca acestea sunt necesare.

O modalitate de a face fata acestor scenarii este de a avea o proprietate care nu poate fi anulata cu un camp de sprijin nul.

adresa privata? _Adresa de transport; adresa publica ShippingAddress {set => _shippingAddress = value; get => _shippingAddress ?? aruncati o noua InvalidOperationException (“Proprietate neinitializata:” + numeleof (ExpediereAdresa)); }

Deoarece proprietatea de navigare nu este nula, este configurata o navigatie necesara; si atata timp cat navigarea este incarcata corect, dependenta va fi accesibila prin proprietate. Daca, totusi, proprietatea este accesata fara a incarca mai intai entitatea corespunzatoare, se lanseaza o InvalidOperationException, deoarece contractul API a fost utilizat incorect. Retineti ca EF trebuie configurat pentru a accesa intotdeauna campul de backing si nu proprietatea, deoarece se bazeaza pe posibilitatea de a citi valoarea chiar si atunci cand nu este setata; consultati documentatia despre campurile de rezerva despre cum sa faceti acest lucru si luati in considerare specificarea PropertyAccessMode.Field pentru a va asigura ca configuratia este corecta.

Ca alternativa terser, este posibil sa initializati pur si simplu proprietatea catre nul cu ajutorul operatorului care ierta nul (!):

produs public produs {get; a stabilit; } = nul !;

O valoare nula reala nu va fi respectata niciodata, cu exceptia unui rezultat al unei erori de programare, de exemplu, accesarea proprietatii de navigatie fara a incarca in prealabil entitatea aferenta.

DbContext si DbSet

Practica obisnuita de a avea proprietati DbSet neinitializate pe tipurile de context este de asemenea problematica, deoarece compilatorul va emite acum avertismente pentru acestea. Acest lucru poate fi fixat dupa cum urmeaza:

public class NullableReferenceTypesContext: DbContext {public DbSet <Customer> Clienti => Set <Customer> (); public DbSet <Order> Orders => Set <Order> (); override protected void OnConfiguring (DbContextOptionsBuilder optionsBuilder) => optionsBuilder .UseSqlServer (@ “Server = (localdb) \ mssqllocaldb; Database = EFNullableReferenceTypes; Trusted_Connection = True; ConnectRetryCount = 0”); }

O alta strategie este de a utiliza proprietati automate care nu pot fi anulate, dar de a le initializa la nul, folosind operatorul de iertare nula (!) Pentru a reduce la avertizare compilatorul. Constructorul de baza DbContext se asigura ca toate proprietatile DbSet vor fi initializate, iar nul nu va fi niciodata observat pe ele.

Navigarea si includerea relatiilor anulabile

Atunci cand aveti de-a face cu relatii optionale, este posibil sa intalniti avertismente ale compilatorului atunci cand o exceptie de referinta nula reala ar fi imposibila. La traducerea si executarea interogarilor dvs. LINQ, EF Core garanteaza ca, daca nu exista o entitate legata optional, orice navigare catre aceasta va fi pur si simplu ignorata, mai degraba decat aruncarea. Cu toate acestea, compilatorul nu este constient de aceasta garantie EF Core si produce avertismente ca si cum interogarea LINQ ar fi executata in memorie, cu LINQ catre obiecte. Ca rezultat, este necesar sa utilizati operatorul de iertare nula (!) Pentru a informa compilatorul ca nu este posibila o valoare nula reala:

Console.WriteLine (order.OptionalInfo! .ExtraAdditionalInfo! .SomeExtraAdditionalInfo);

O problema similara apare atunci cand se includ mai multe niveluri de relatii intre navigatiile optionale:

var order = context.Orders .Include (o => o.OptionalInfo!) .ThenInclude (op => op.ExtraAdditionalInfo) .Single ();

Daca faceti acest lucru mult si tipurile de entitati in cauza sunt utilizate in mod predominant (sau exclusiv) in interogarile EF Core, luati in considerare ca proprietatile de navigare sa nu fie anulabile si sa le configurati ca optionale prin intermediul API-ului Fluent sau Adnotari de date. Aceasta va elimina toate avertismentele compilatorului, pastrand relatia optionala; cu toate acestea, daca entitatile dvs. sunt traversate in afara EF Core, puteti observa valori nule, desi proprietatile sunt adnotate ca nevalabile.

Limitari

• Ingineria inversa nu accepta in prezent tipuri de referinta nullable C # 8 (NRT): EF Core genereaza intotdeauna cod C # care presupune ca caracteristica este dezactivata. De exemplu, coloanele de text care pot fi anulate vor fi esafodate ca o proprietate cu sir de tip, nu sir ?, fie cu Fluent API, fie cu Adnotari de date utilizate pentru a configura daca este necesara sau nu o proprietate. Puteti edita codul esafodat si le puteti inlocui cu adnotari de nulitate C #. Suportul pentru schele pentru tipurile de referinta nulabile este urmarit de numarul # 15520.
• Inainte de EF Core 6.0, suprafata API-ului public nu era adnotata pentru nulitate (API-ul public era „nul”, ceea ce face uneori dificil de utilizat cand functia NRT este activata. Aceasta include in special operatorii LINQ asincri expusi de EF Core, cum ar fi FirstOrDefaultAsync. API-ul public este complet adnotat pentru nulitate incepand cu EF Core 6.0.