it-swarm.com.de

Ist das Erstellen von ViewModels in der Web-API eine schlechte Praxis?

Jemand bei der Arbeit, der doppelt so erfahren ist wie ich, sagte uns, dass wir keine ViewModel Klassen erstellen dürfen innerhalb der Web-API. (Wir verwenden Angular für UI)

Seiner Meinung nach ist ViewModel ein ASP.NET MVC-Ansatz. Und wir müssen herauskommen, wenn wir die Web-API verwenden.

Hier ist mein Argument für die Verwendung von ViewModel in WebAPIs:

Datenbanktabellen

Mitarbeiter

name | phone | categoryId |...Col15

Kategorie

categoryId | Description

C # Klasse

Class Employee
{
 public string name {get;set;}
 public phone {get;set;}
 public categoryId {get;set;}
 //...till col15
}

Wenn auf Ihrer UI-Seite nur angezeigt wird :

 name | phone | categoryId | CategoryDescription

Wäre es nicht sinnvoll, eine ViewModel -Klasse in der API zu erstellen, die im Gegensatz zu allen 15 Eigenschaften nur diese 4 Eigenschaften aufweist? Der JSON, der von dieser Klasse zurückgegeben wird, hat nur 4 Eigenschaften anstelle von 15 Eigenschaften, von denen 11 einen Nullwert enthalten.

Wenn es eine Liste mit beispielsweise 100 Mitarbeitern gibt, bedeutet dies 1100 Leere JSON-Eigenschaften, die an die Benutzeroberfläche gesendet werden, wenn anstelle einer ViewModel -Klasse die ursprüngliche Employee-Klasse verwendet wird.

Wenn wir uns an unsere ursprüngliche Mitarbeiterklasse halten, müssen wir möglicherweise eine der folgenden Aktionen ausführen :

  1. CategoryDescription muss zur ursprünglichen Employee-Klasse hinzugefügt werden
  2. Führen Sie einen zweiten API-Aufruf über die Benutzeroberfläche durch, um die Beschreibung abzurufen.
2
SamuraiJack

Was Sie tun, ist in Ordnung. Sie sollten nur die Daten verfügbar machen, die für die Clients erforderlich sind.

Nennen Sie es einfach nicht "Ansichtsmodelle", da dieser Begriff im Kontext von Benutzeroberflächen eine bestimmte Bedeutung hat und bei Verwendung außerhalb dieses Kontexts Verwirrung stiftet. Nennen Sie es "Datenübertragungsobjekte" und jeder wird glücklich sein.

Es ist keine gute Idee, Entitäten direkt über eine API verfügbar zu machen. Dies führt zu einer engen Kopplung, was bedeutet, dass geringfügige Änderungen in der Geschäftslogik zu Änderungen in der API führen (und umgekehrt). Das wollen Sie vermeiden.

1
JacquesB

Im Prinzip werden Frontend-Frameworks wie Angular] am besten gegen eine REST API) verwendet, was bedeutet, dass Sie keine Ansichtsmodelle haben und Ihre Ressourcen einfach so verfügbar machen, wie sie sind sind.

Nach dem Sound verwenden Sie jedoch keine REST API), sondern eine API, die auf die Anforderungen der Frontend-Anwendung zugeschnitten ist. Ich sage dies, weil Sie erwähnen, dass die API speziell - lässt weg 11 von 15 Eigenschaften, da es weiß, dass das Frontend sie für diesen speziellen Fall nicht benötigt.

Wenn dies der Fall ist, kennt Ihre API Ihre Frontend-Anwendungsansichten von Natur aus und Sie arbeiten effektiv mit Ansichtsmodellen. Anscheinend schlägt Ihr Kollege lediglich vor, kein explizites Ansichtsmodell zu erstellen, und versucht stattdessen, vorhandene DTOs wiederzuverwenden, jedoch mit Eigenschaften, die absichtlich leer gehalten werden. Dies ist keine gute Vorgehensweise.

Zusammenfassend funktioniert die Haltung "keine Ansichtsmodelle" , wenn Sie eine REST API) haben. Wenn Sie eine haben API, die benutzerdefinierte Anforderungen verarbeitet und Daten automatisch redigiert, weil sie weiß, was das Frontend anzeigt/nicht anzeigt. Die Haltung "Keine Ansichtsmodelle" widerspricht der Entwicklung der API.


Zusätzlich:

Seiner Meinung nach ist ViewModel ein ASP.NET MVC-Ansatz.

MVC steht für Model-View-Controller. MVC hat keine Ansichtsmodelle. MVVM (Model-View-ViewModel) verfügt jedoch über Ansichtsmodelle.

Ich bin nicht sicher, ob diese Verschmelzung auf Ihrer Seite oder auf der Seite Ihres Kollegen liegt, aber es ist nahezu unmöglich, die Verwendung von Ansichtsmodellen (oder deren Fehlen) produktiv zu diskutieren, wenn eine der Parteien MVC und MVVM nicht unterscheiden kann.
Zumindest würden Sie den falschen Namen verwenden (Ansichtsmodell vs. Modell), was es für andere Personen sehr schwierig macht, basierend auf Ihrer Erklärung genaues Feedback zu geben.

1
Flater

Ja, es ist eine schlechte Praxis.

Im Wesentlichen verschieben Sie die Logik von Ihrer Javascript-Clientanwendung auf die Serverseite.

Dies funktioniert gut, wenn Sie Seitenanforderungen mit wenig oder keiner clientseitigen Logik stellen, aber nicht, wenn Sie eine einzelne Seiten-App haben, bei der die gesamte Präsentationslogik zumindest clientseitig sein soll, um die verschiedenen Vorteile zu nutzen, die sich daraus ergeben können .

Wenn Sie in Ihrem ersten Beispiel das EmployeeViewModel mit reduzierten Feldern erstellen und später eines dieser Felder am Frontend benötigen, müssen Sie jetzt sowohl das Frontend als auch das Backend bearbeiten.

in Ihrem zweiten Beispiel, in dem Sie den Mitarbeiter mit der Kategoriebeschreibung bereichern, ist Ihr Kunde durchaus in der Lage, die Informationen separat anzufordern, im Speicher zu halten und mit Mitarbeitern zu verknüpfen, sie in Dropdowns usw. usw. zu verwenden

In jedem Fall verringert das Hinzufügen eines Ansichtsmodells zum Server die Flexibilität und die verfügbaren Optionen in Ihrem clientseitigen Code

1
Ewan

Wenn Sie in Ihrem Web-API-Projekt ein Repository-Muster verwenden, empfiehlt es sich in diesem Fall, das Ansichtsmodell für die direkte Interaktion mit der Datenbank von der Front-End-Seite aus zu verwenden. In anderen Fällen können Sie Vorgänge ausführen, ohne Ansichtsmodelle zu verwenden.

0
Ishan Shah