none
Designfrage MVC verschiedene Models für Anzeige und Bearbeitung? RRS feed

  • Frage

  • Hallo zusammen,

    mich beschäftigt gerade eine Designfrage beim Aufbau der Models für eine Web-API. Es stellt sich mir die Frage, ob man für die Anzeige und Bearbeitung und letztlich auch für die Neuanlage immer das gleiche Model nimmt. Dabei geht es mir speziell um Eigenschaften, welche zwar für die Anzeige wichtig sind, welche aber nicht - zumindest nicht per WEB-Client - verändert werden dürfen.

    Ich habe zum Beispiel ein "Dokument" mit einer "Kategorie". Mein "DokumentViewModel" hätte also eine Eigenschaft "Kategorie" und da steht beispielsweise "Allgemein" drin. Eine weitere Eigenschaft wäre der "Suchbegriff". Der Webclient darf und soll die Kategorie darstellen, aber nur den Suchbegriff zum Ändern freigeben.

    Würde man hier zusätzlich so etwas wie ein "DokumentEditModel" bauen, welches nur die editierbaren Eigenschaften enthält? Der zum Dokument gehörende Controller, also der "DokumentController" hat ja eine "Edit-Methode, welche ja das geänderte Dokument in irgendeiner Form erwartet Wenn ich hier das ursprüngliche "DokumentViewModel" wieder erwarte, so müsste ja der Webclient immer "wissen", welche Eigenschaften davon überhaupt sinnvoll zu belegen sind. Da wäre möglicherweise ein "DokumentEditModel" besser, oder? Die gleiche Frage stellt sich ja bei der Neuanlage, also dem "Create", da sind ja oft auch nicht alle Eigenschaften sinnvoll von außen zu belegen...

    Oder habe ich hier einen kapitalen Denkfehler?

    Gruß, Karsten.

    Mittwoch, 3. März 2021 15:32

Antworten

  • Hallo Karsten,

    bei MVC entscheidet weder der Controller noch das Model wie der View die Daten anzeigt oder was er damit macht. Das entscheidet nur die View. Wann ein ViewModel sinnvoll ist muss Du für dich selbst rausfinden. 

    Ich würde natürlich niemals den gesamten ASP.NET Core Identity User zurückgeben und mir auch keinen gesamten Datensatz geben lassen. Hier verwende ich auch ein ViewModel vielleicht auch ein anderes für Register/Create.

    Der Zweck heiligt die mittel


    Gruß Thomas
    Github

    Donnerstag, 4. März 2021 21:04
  • Hallo Karsten,

    Wenn Du Entitätsklassen hast, kannst Du die Entität zunächst aus der Datenbank lesen und TryUpdateModel aufrufen, und die explizit aufgezählten Eigenschaften übergeben. Für weitere Informationen (z. B. im Hinblick auf das Bind-Attribut) verweise ich Dich auf diesen Artikel, der darüber hinaus noch ein, für ein Ansichtsmodell geeignetes Verfahren zum Vermeiden von Overposting behandelt:
    Sicherheitshinweis zum Overposting

    Gruß,
    Dimitar


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Donnerstag, 4. März 2021 07:51
    Moderator

Alle Antworten

  • Hallo Karsten,

    Wenn Du Entitätsklassen hast, kannst Du die Entität zunächst aus der Datenbank lesen und TryUpdateModel aufrufen, und die explizit aufgezählten Eigenschaften übergeben. Für weitere Informationen (z. B. im Hinblick auf das Bind-Attribut) verweise ich Dich auf diesen Artikel, der darüber hinaus noch ein, für ein Ansichtsmodell geeignetes Verfahren zum Vermeiden von Overposting behandelt:
    Sicherheitshinweis zum Overposting

    Gruß,
    Dimitar


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Donnerstag, 4. März 2021 07:51
    Moderator
  • Hallo Dimitar,

    die TryUpdateModel erscheint mir ganz praktisch, das kannte ich noch gar nicht, aber das schaue ich mir noch an. Darüber hinaus bin ich aber noch am Überlegen, ob ich zumindest für die Neuanlage noch passende Models erstelle, welche nur die Eigenschaften enthalten, die für die Neuanlage nötig sind.

    Ich danke dir erstmal für deine Antwort,

    Gruß, Karsten.

    Donnerstag, 4. März 2021 17:44
  • Hallo Karsten,

    bei MVC entscheidet weder der Controller noch das Model wie der View die Daten anzeigt oder was er damit macht. Das entscheidet nur die View. Wann ein ViewModel sinnvoll ist muss Du für dich selbst rausfinden. 

    Ich würde natürlich niemals den gesamten ASP.NET Core Identity User zurückgeben und mir auch keinen gesamten Datensatz geben lassen. Hier verwende ich auch ein ViewModel vielleicht auch ein anderes für Register/Create.

    Der Zweck heiligt die mittel


    Gruß Thomas
    Github

    Donnerstag, 4. März 2021 21:04
  • Hallo zusammen,

    ich habe jetzt eine Möglichkeit für mich gefunden: Es gibt für jede Möglichkeit der Neuanlage von Daten das passende Model. Die Models sind teilweise natürlich identisch, dort wo auch gleiche Daten von außen reinkommen, aber jedes Model deckt exakt eine Möglichkeit zur Neuanlage von Daten ab. Zum Editieren und Anzeigen nehme ich das gleiche Model, wobei nicht jede Eigenschaft editierbar ist.

    Damit habe ich unterschiedliche Sätze von Models für Editierzwecke oder für Neuanlagezwecke. Das macht es für den Webclient einfacher. Bei der Neuanlage kann ich alle Daten des Models verarbeiten, weil das ja genau dafür gedacht ist, beim Editieren werden ggf. ein paar Eigenschaften ignoriert, welche nur zum Anzeigen gedacht sind.

    Danke euch beiden für die die Lösungsansätze.

    Gruß, Karsten.

    Mittwoch, 10. März 2021 14:50