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 o
tí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átid
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.