Nem létezik az adott idegen kulcs, kivételkezelés c#

Nem létezik az adott idegen kulcs, kivételkezelés c#
2020-11-22T12:45:08+01:00
2020-11-23T12:55:52+01:00
2022-10-15T21:25:38+02:00
Lechu947
Sziasztok!

Azt szeretném megkérdezni, hogyha az entity framework core adatbázisomban van új elem felvétele lehetőségem, és az új elemnél meg kell andom idegen kulcsot is, akkor azt a kivételt melyik régeben kell lekezelnem, hogyha a felhasználó nem létehő idegen kulcsot akar megadni?
A repository-ban, vagy a logic-ban? És hogyan kéne megcsinálnom?
Csak mert ugye le tudom kérdeni, hogy benn van-e az adott id- az adatbázisban, viszont az új elem felvétele metódusomban a paraméter DbContext entity, és nem pedig is.

Pl.

Van egy film, és annak vannak szereplői, és a szereplőnél meg szereném adni, hogy melyik filmben szerepelt, viszont a megadott ID-jű film nem szerepel az adatbázisban.

Köszönöm szépen előre is!
Mutasd a teljes hozzászólást!

  • Itt ugye létrejön egy kapcsolat a film és a szereplő között. Ilyet én úgy szoktam, hogy:
    - lekérem a film-et id alapján, ha nincs, akkor kivétel dobás (ezt már a repositoryban elintézem egy EntityNotFoundException dobásával, ami kijuthat a rest rétegre is, ezt nem kapom el az üzleti logikai rétegben, így ott nem kell ezzel foglalkozni)
    - lekérem a szerzőt id alapján, ha nincs, akkor kivétel dobás
    - megnézem, hogy létezik-e már ilyen összerendelés a kettő között, ha van már ilyen, akkor kivétel dobás (ezt viszont az üzleti rétegből dobom)

    Magyarán szépen végigvalidáljuk, hogy az összes adat rendelkezésre áll-e/nincs-e már ott, és akkor már nem futhat váratlan hibára a DB művelet

    Érdemes megfontolni, hogy az egész egy tranzakcióban menjen.
    Mutasd a teljes hozzászólást!
  • 1./ erőforrás igényes, ha nem GUI és felhasználó a sebesség, hanem valami kódban történik a dolog
    2./ több felhasználós környezetben a hajadra kenhetted, ha a GUI-ban szépen ellenőrzött minden, de mire az "OK, felvihető" gombig jut a user, addig kétszer megváltozik az adatbázis.
    Mutasd a teljes hozzászólást!
  • + guiból régen rossz, ha a DB direktben elérhető
    - Igen, erőforrásigényes, de van ahol szigorúak az elvárások :)
    - Ezért kell tranzakcióban futtatni szerveroldalon.
    Mutasd a teljes hozzászólást!
  • + guiból régen rossz, ha a DB direktben elérhető


    A GUI azt jelenti, hogy a user (ember!) tempója szerint t9rtének a dolgok.De nem az a lényeg, hogy hány réteggel alább, hanem hogy GUI esemény hatására történik adatellenőrzés az adatforrásban,


    "- Igen, erőforrásigényes, de van ahol szigorúak az elvárások :)"
    A szakértelem néha meghajol a marketingesek nyomása alatt. DE valóban létezik optimum az adatellenőrzések mennyiségében. Ha értelmezhető esélye van, akkor illik előre ellenőrizni (lásd készleten van-e) ha meg alacsony a valószínűség, akkor hagyjuk az adatbázisba írásra az ellenörzést, különösen mivel automatizmus constraintek mentés, így kisebb hibaforrás, (pl. törzsadatok létezésének ellenőrzése)

    "- Ezért kell tranzakcióban futtatni szerveroldalon."
    Komoly élmény egy deadlockokkal teletűzdelt rendszeren dolgozni :)
    Mutasd a teljes hozzászólást!
  •  "- Ezért kell tranzakcióban futtatni szerveroldalon."

    Komoly élmény egy deadlockokkal teletűzdelt rendszeren dolgozni :)

    Tranzakciók használata miért vezetne szükségszerűen deadlock-hoz?

    Megfelelő isolation level-t kell választani és konzisztens adatokat kapsz, deadlock nélkül, gyorsan.
    Mutasd a teljes hozzászólást!
  • Kliens oldali összes adatbázis constraint ellenőrzés (tipikusan user interakció is) esetén?
    Mutasd a teljes hozzászólást!
  • Van egy film, és annak vannak szereplői, és a szereplőnél meg szereném adni, hogy melyik filmben szerepelt, viszont a megadott ID-jű film nem szerepel az adatbázisban.

    Szia!

    Tipikusa a bilire ülés fordított esete.
    Film>-Film_szereplői->Színész
    3 tábla.
    A filmek adottak, fel vannak véve a filmek közé.
    Miden filmek van ID-ja.
    A színészek fel vannak véve a színész táblába, mindegyiknek ID-ja van.
    A Film_szereplőibe Film és színész ID-k kerülnek párosával.
    Soha nem fogsz olyan filmet tudni kiválasztani ami nincs felvéve, ha listából választ.
    Alapvetően nem is értem hogy tud a user olyan filmet kiválasztani ami nincs az adatbázisban??????
    Miért nem listából választ a szerencsétlen user?
    Miért kellene neki fejből köpni/vágni az összes film ID-ját?

    Akár nem is kellene tudnia arról hogy létezik ID.
    Se film se színész ID....
    Mutasd a teljes hozzászólást!
  • Ezt nem nagyon értem.

    Egyfelől teljesen mindegynek tűnik, hogy kliens vagy szerver oldalról használunk tranzakciót, nem ettől lesz deadlock. Erre reagáltam, a tranzakció és a deadlock kapcsolatára.

    Másfelől immár jó ideje általában nem is érdemes másban gondolkodni, mint kliens/szerveres megoldásban, senki nem is javasolta itt, hogy a kliens direktben olvasson db-t.
    Mutasd a teljes hozzászólást!
  • Az adatbázis konzisztenciájának biztosítása mindenképp az adatelérési réteg feladata. Más kérdés, hogy egy SQL rendszer biztosítja a konzisztenciát, ha megfelelően vannak létrehozva a táblák és jól be vannak állítva a constraint-ek, viszont egy NoSQL alapú rendszer esetén (pl. a dokumentum-elvű DynamoDB) a rendszer ezt nem tudja biztosítani, helyette erről kézzel kell gondoskodnod. Függetlenül attól, hogy mi az underlying adatbázis - bár az EF Core-ból ítélve SQL - a business logic layer így akarja kezelni az adatbázisba mentést:

    public interface IMovieDataManager { Task<bool> AddActorToMovie(MovieBE movie, ActorBE actor); }
    (BE = Business Entity, az üzleti logikai rétegben alkalmazott modell)

    Persze bool helyett megoldható kivételkezeléssel is, ez hitvallás kérdése. A lényeg az, hogy az adatelérési rétegnek el kell rejtenie az adatbázis-kezelő rendszer vagy ORM által kiváltott kivételeket, és olyan formára kell hozni az eredményt, amit a business logic layer elvár.

    Az, hogy a háttérben mi történik, az már nem a business logic layer felelőssége, hanem az adatelérési rétegé. SQL adatbázis esetén az ORM rendszer (EF Core) kivétellel fogja jelezni, ha sérül a foreign key constraint, például olyan szereplőt akarsz hozzáadni egy filmhez, aki nem létezik. NoSQL esetén az adatelérési réteg ellenőrzi, hogy létezik-e a szereplő és a film - ha valamelyik nem létezik, akkor ezt megfelelően jelenti a business logic layernek.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd