EF Core Rest hierarchische Struktur generisch sicherstellen

  • C#

    EF Core Rest hierarchische Struktur generisch sicherstellen

    Hi,vielleicht kann mir ja einer helfen.Ich habe ein Datenmodell mit Beziehungen über PK->FK ganz normal.
    Es gibt eine Tabelle Location.
    Alle anderen setzen auf eine Location auf. Also zum Beispiel Tabelle Departement ist über eine FK einer Location zugeordnet. Ein Department wieder kann viele Artikel haben. Soweit so gut.

    Des weiteren gibt es User die einem oder mehreren Locations zugeordnet sein können. Über eine Auflösungstabelle UserLocation ist diese M zu N Beziehung realisiert.
    Diese Struktur ist nun über einen REST Service in ASP NET Core und EF Core konsumierbar.
    Es gibt also GET, POST, PUT, DELETE um entsprechende Resourcen in der Datenbank zu ändern.
    Die Abfragen sind auch eingeschränkt via Rollen so dass der User nur seine Locations abfragen kann und mit Hilfe von Rollen zB nur Get oder alles machen kann.

    Ein RestCall Post auf einen Artikel sieht nun so aus:

    POST: /locations/id/departments/id/articles

    Es gibt aber generell mehr als nur Artikel, die alle vom selben Prinzip aufbauen. Locations ist der Root und dann gibt es weitere verschachtelte in Beziehung stehende Resourcen.Das funktioniert soweit auch gut.
    Meine Frage ist nun. Es könnte ja jemand daher kommen und versuchen in eine location auf die er Zugriff hat nun einfach eine andere DepartmentID anzuhängen, die nicht in der Location steht, und diesem Department dann einen Artikel hinzufügen.

    Als Beispiel:

    User AdminUdo hat Zugriff auf Location 1. Aber nicht auf 2. Er darf aber Posts/deletes usw senden.Department 1 gehört zu Location 1 und Department 2 zu Location 2
    Dann wären folgende Calls möglich für User AdminUdo


    POST /locations/1/departments/1/articles <- einen neuen Artikel anlegen in Location 1/Department 1 geht und ist in Ordnung. Die Location ID wird abgeglichen und passt
    POST /locations/2/departments/2/articles <- einen neuen Artikel anlegen in Location 2 geht nicht und wird verboten (egal welches Department)
    POST /locations/1/departments/2/articles <- einen neuen Artikel anlegen in Location 1 geht prinzipiell, aber Department 2 gehört gar nicht zu Location 1. Der Artikel selber hat aber nur einen Bezug zu department, und der passt


    Wie kann ich das verhindern ohne für jeden Call die Abfragen nach unten alle zu schreiben?
    Meine Idee war, in der WebAPI den Pfad vor dem eigentlichen Call auszulesen und anhand der Namen die entsprechenden Entitäten in EF Core Anhand des Strings über Reflection auszulesen und dann nach unten durch zu querien.
    Habe es aber bisher nicht hinbekommen die DBSets mit und deren Entitäten über die NavigationProperties zu laden.

    Ich hab ein paar Versuche gestartet aber es noch nicht hinbekommen:

    Spoiler anzeigen

    C#-Quellcode

    1. 'NavigationProperties:
    2. using (var c = GetContext())
    3. {
    4. const string entityName = "articles";
    5. const string parentName = "departments";
    6. var modelData = c.Model.GetEntityTypes()
    7. .Where(e => e.ClrType.Name.ToLower() == entityName.ToLower())
    8. .Select(t => new
    9. {
    10. NavigationProperties = t.GetNavigations()
    11. .Where(n => n.ClrType.Name.ToLower() == parentName.ToLower())
    12. });
    13. --Konnte dann damit aber nichts wirklich abfragen.



    Spoiler anzeigen

    C#-Quellcode

    1. var ent = c.Model.FindEntityType("Departements");
    2. public virtual Guid GetKey<T>(T entity, MyContext context)
    3. {
    4. var keyName = context.Model.FindEntityType(typeof(T)).FindPrimaryKey().Properties
    5. .Select(x => x.Name).Single();
    6. return (Guid) entity.GetType().GetProperty(keyName).GetValue(entity, null);
    7. }


    Ich muss dazu sagen das ich noch nicht allzu lange daran sitze, da ich mir denke das es eine bessere Lösung geben müsste.
    Für die Route hätte ich schon alle Teile als Strings und deren Id's die dann die Primary Keys wären, die man abfragen müsste.
    Alle PK's heißen Id und sind vom Typ Guid.
    Wenn es nicht ganz klar formuliert ist werde ich gerne noch mehr posten.

    LG
    Das ist meine Signatur und sie wird wunderbar sein!