Megosztás a következőn keresztül:


Objektumállapotok és változáskövetés

A LINQ–SQL-objektumok mindig valamilyen állapotban vesznek részt. Ha például a LINQ to SQL létrehoz egy új objektumot, az objektum állapotban Unchanged van. A saját maga által létrehozott új objektum ismeretlen, DataContext és állapotban Untracked van. A sikeres végrehajtást követően a SubmitChangesLINQ-ról SQL-hez ismert összes objektum állapota folyamatban van Unchanged . (Az egyetlen kivételt azok képviselik, amelyek sikeresen törölve lettek az adatbázisból, amelyek állapotban Deleted vannak és nem használhatók az adott DataContext példányban.)

Objektumállapotok

Az alábbi táblázat a LINQ és az SQL-objektumok lehetséges állapotát sorolja fel.

Állapot Leírás
Untracked A LINQ által az SQL-be nem követett objektum. Ilyenek például a következők:

- Az objektum nem az aktuális DataContext (például újonnan létrehozott) objektumon keresztül kérdezhető le.
- Deszerializálással létrehozott objektum
- Egy objektum lekérdezett egy másik DataContext.
Unchanged Az aktuális DataContext és a létrehozás óta nem ismert módosítással lekért objektum.
PossiblyModified Egy objektum, amely egy DataContext. További információ: Adatlekérési és CUD-műveletek az N szintű alkalmazásokban (LINQ–SQL).
ToBeInserted Nem az aktuális DataContexthasználatával lekért objektum. Ez egy adatbázist INSERT okoz a .SubmitChanges
ToBeUpdated Egy olyan objektum, amelyről ismert, hogy a lekérése óta módosult. Ez egy adatbázist UPDATE okoz a .SubmitChanges
ToBeDeleted Törlésre jelölt objektum, amely adatbázist DELETE okoz a törlés során SubmitChanges.
Deleted Az adatbázisban törölt objektum. Ez az állapot végleges, és nem teszi lehetővé a további áttűnéseket.

Objektumok beszúrása

Explicit módon kérheti Inserts a következőt InsertOnSubmit: . Azt is megteheti Inserts , hogy az SQL-hez való LINQ az egyik frissítendő ismert objektumhoz csatlakoztatott objektumok megkeresésével következtet. Ha például objektumot Untracked ad hozzá egy EntitySet<TEntity> objektumhoz, vagy beállít egy EntityRef<TEntity> objektumot Untracked , akkor az Untracked objektumot a gráfban nyomon követett objektumok segítségével érheti el. A feldolgozás SubmitChangessorán a LINQ–SQL bejárja a nyomon követett objektumokat, és felderíti a nem nyomon követett, elérhető állandó objektumokat. Ezek az objektumok az adatbázisba való beszúrásra jelölt objektumok.

Az öröklési hierarchiában InsertOnSubmitlévő osztályok esetében (o) a diszkriminatívként kijelölt tag értékét is beállítja az objektum otípusának megfelelően. Az alapértelmezett diszkriminatív értéknek megfelelő típus esetén ez a művelet a diszkriminatív értéket felülírja az alapértelmezett értékkel. További információ: Öröklési támogatás.

Fontos

A hozzáadott Table objektumok nem az identitás-gyorsítótárban találhatóak. Az identitásgyorsítótár csak az adatbázisból lekért adatokat tükrözi. A hívás InsertOnSubmitután a hozzáadott entitás csak akkor jelenik meg az adatbázis lekérdezéseiben, ha SubmitChanges sikeresen befejeződött.

Objektumok törlése

A korrektúra objektumot o törlésre megjelölheti a megfelelő Table<TEntity>(o) hívásávalDeleteOnSubmit. A LINQ to SQL frissítési műveletnek tekinti egy objektum eltávolítását egy EntitySet<TEntity> frissítési műveletből, és a megfelelő idegenkulcs-érték null értékre van állítva. A művelet (o) célja nem törlődik a táblából. Például azt a frissítést jelzi, cust.Orders.DeleteOnSubmit(ord) ahol az idegen kulcs ord.CustomerID null értékűre állításával megszakad a kapcsolat a kettő között cust ord. Ez nem okozza a megfelelő sor törlését ord.

A LINQ to SQL a következő feldolgozást hajtja végre, amikor egy objektumot töröl (DeleteOnSubmit) a táblából:

  • Amikor SubmitChanges a rendszer meghívja, DELETE a rendszer műveletet hajt végre az adott objektumon.

  • Az eltávolítás nem propagálja a kapcsolódó objektumokra, függetlenül attól, hogy betöltötték-e őket. A kapcsolódó objektumok nincsenek betöltve a kapcsolattulajdonság frissítéséhez.

  • A sikeres végrehajtás SubmitChangesután az objektumok állapotra Deleted vannak állítva. Ennek eredményeként nem használhatja az objektumot vagy annak az objektumát id DataContextebben a fájlban. A példány által DataContext karbantartott belső gyorsítótár nem szünteti meg a lekért vagy újként hozzáadott objektumokat, még akkor sem, ha az objektumokat törölték az adatbázisban.

DeleteOnSubmit Csak a DataContext. Egy Untracked objektumhoz a hívás előtt fel kell hívnia a hívást Attach DeleteOnSubmit. Egy Untracked objektum meghívása DeleteOnSubmit kivételt eredményez.

Feljegyzés

Ha eltávolít egy objektumot egy táblából, a LINQ-nak az SQL-nek kell létrehoznia egy megfelelő SQL-parancsot DELETE SubmitChangesaz adott időpontban. Ez a művelet nem távolítja el az objektumot a gyorsítótárból, és nem propagálja a törlést a kapcsolódó objektumokra.

A törölt objektumok visszaigényléséhez id használjon egy új DataContext példányt. A kapcsolódó objektumok törléséhez használhatja az adatbázis kaszkádolt törlési funkcióját, vagy manuálisan törölheti a kapcsolódó objektumokat.

A kapcsolódó objektumokat nem kell külön sorrendben törölni (az adatbázistól eltérően).

Objektumok frissítése

A változások értesítéseinek megfigyelésével észlelheti azokat Updates . Az értesítések az PropertyChanging eseményen keresztül jelennek meg a tulajdonságválasztókban. Amikor az SQL-hez tartozó LINQ értesítést kap az objektum első módosításáról, létrehoz egy másolatot az objektumról, és az objektumot egy utasítás létrehozására Update jelöltnek tekinti.

A nem implementált INotifyPropertyChangingobjektumok esetében a LINQ az SQL-hez fenntartja az objektumok első materializálásakor kapott értékek másolatát. Híváskor SubmitChangesa LINQ az SQL-hez összehasonlítja az aktuális és az eredeti értékeket, hogy eldöntse, módosították-e az objektumot.

A kapcsolatok frissítéséhez a gyermek és a szülő közötti hivatkozás (vagyis az idegen kulcsnak megfelelő hivatkozás) a hatóságnak minősül. A fordított irányban (azaz szülőről gyermekre) történő hivatkozás nem kötelező. A kapcsolatosztályok (EntitySet<TEntity> és EntityRef<TEntity>) garantálják, hogy a kétirányú hivatkozások konzisztensek az egy-a-többhöz és az egy-az-egyhez kapcsolatokhoz. Ha az objektummodell nem használja EntitySet<TEntity> , vagy EntityRef<TEntity>ha a fordított hivatkozás jelen van, az Ön felelőssége, hogy a kapcsolat frissítésekor konzisztens legyen a továbbítási hivatkozással.

Ha frissíti a szükséges hivatkozást és a megfelelő idegen kulcsot is, győződjön meg arról, hogy azok megegyeznek. Kivétel InvalidOperationException akkor történik, ha a rendszer nem szinkronizálja a kettőt a hívás SubmitChangesidőpontjában. Bár az idegen kulcs értékének módosítása elegendő a mögöttes sor frissítésének befolyásolásához, módosítania kell a hivatkozást az objektumdiagram kapcsolatának fenntartása és a kapcsolatok kétirányú konzisztenciájának fenntartása érdekében.

Lásd még