it-swarm.com.de

Ist es sinnvoll, ViewModels in der Web-API zu haben?

Ich fange an, das Webapi zu lernen und finde mich dabei, Dinge zu tun, die in einem MVC-Projekt sinnvoll sind, in denen es aber möglicherweise keinen Sinn ergibt.

Normalerweise erstelle ich in einem MVC-Projekt ViewModels und verwende diese als Parameter oder gebe sie mit der Ansicht zurück.

Da es in webapi keine Views gibt, ist es meines Erachtens nicht sinnvoll, ein ViewModel als Parameter zu haben.

Ich frage mich vielleicht, ob ich nur meine EF-Domänen (Code zuerst) als Parameter haben und Datenanmerkungen darüber setzen sollte. Normalerweise würde ich die Anmerkungen über die Eigenschaften des Ansichtsmodells platzieren, so wie es mir in der Domäne gefallen hat.

Was mich jedoch davon abhält, ist, dass mir nicht 100% klar ist, wie meine MVC-Site funktionieren würde.

Spuckt die MVC-Site nur einfache Ansichten zurück und rufen Sie Ihre Webapi dann mit Jquery auf, oder rufen Sie nur MVC-Aktionsmethoden auf, die direkt dieselben Methoden aufrufen, die die Webapi aufrufen würde?

Wenn dies der zweite Weg ist, füge ich die Datenanmerkungen lieber erneut in mein Ansichtsmodell ein, aber dann füge ich die gleichen Anmerkungen sowohl in die EF-Domäne als auch in die VMs ein und das scheint überflüssig.

62
chobo2

Abgesehen von der Terminologie sind Modelle zum Binden immer noch von Nutzen. Technisch gesehen sind sie keine ViewModels mehr, Sie haben also Recht, es sind keine Views involviert. Aber sie sind definitiv noch von Nutzen. Wenn Sie sie verwenden, können Sie Attribute in den Eigenschaften Ihres Modells nutzen und sie bei Bedarf in Ihrer API wiederverwenden. Denken Sie auch daran, wenn Sie Ihre Entitäten direkt verwenden, bindet das WebAPI-Modell alle Parameter, die mit dem Namen übereinstimmen, an diese, auch wenn Sie dies nicht wollten.

Die Entitätsmodelle sind auch Darstellungen Ihrer Rohdaten, die für die Bindung verwendeten Modelle sind jedoch ein fester Vertrag, den die API-Anforderungen erfüllen müssen, um eine Anforderung erfolgreich zu verarbeiten. Die Werte, die sich zum Zeitpunkt der Implementierung möglicherweise über mehrere Entitätsmodelle erstrecken, werden nicht in einem Datenspeicher gespeichert.

30
Nick Albrecht

Mein Vorschlag nach langer Zeit mit diesen 'Dingen' zu arbeiten :

BindingModels für Datenbindung (MVC oder API)

ViewModels für ansichten auf mvc (möglicherweise haben sie einige mvc seiten in ihrem api, es ist also gut einen platz dafür zu haben, dies kann dokumentation sein, intro seite, was auch immer. Wenn es keine ansicht gibt, dann Sie können null ViewModels haben.) Ein Vorteil davon ist, dass Sie in Ihrer Views/web.config die ViewModels-Namespace-Referenz haben können und diese nicht mit Ihren API-Ressourcen verschmutzt wird.

ResourceModel für Web-API-Ressourcen. In webapi sind verschachtelte Ressourcen auch Ressourcen, die sich an einer beliebigen Stelle in einem Baum befinden, die in mvc nicht so häufig vorkommt. Daher ist es sehr sinnvoll, sie Ressourcen zu nennen.

Wenn Sie eine Ressource erhalten möchten, können Sie Ihr Ressourcenmodell verwenden. Denken Sie daran, dass Sie dasselbe empfangen, das Sie zurücksenden.

Wenn Sie eine benutzerdefinierte Bindung für die Eingabe wünschen (dies sollte Ihr Standardszenario sein), haben Sie Ihre Bindungsmodelle.

Verwenden Sie Ihre ViewModels, wenn Sie über eine MVC-Ansicht verfügen, für Verwaltungszwecke oder zur Dokumentation.

Wenn Sie eine Formularseite auf mvc haben, können Sie Ihr BindingModel auch auf dem POST Controller verwenden. Für einen Beitrag auf MVC oder WEBAPI ist kein anderes Modell erforderlich. Dies gilt insbesondere für Modellordner oder Formatierer können dasselbe Bindungsmodell mit denselben Datenanmerkungen verstehen und zuordnen.

Manchmal möchten Sie ein Bindungsmodell mit einer Ressource und einigen zusätzlichen Feldern erstellen. Vererbung ist dein Freund.

Manchmal möchten Sie ein Bindungsmodell mit mehr als einer Ressource und (optional) zusätzlichen Feldern erstellen. Ressourcen als Eigenschaften sind Ihre Freunde.

In der MVC-Welt können Sie auch das Konzept "Ressource" verwenden, es ist jedoch viel seltener. Dies ist praktisch, wenn Sie MVC und Web Api im selben Projekt haben.

Wenn Sie weitere Kommentare zu einem Element benötigen (z. B. Ordnerstruktur, Namespaces usw.), lassen Sie es mich einfach wissen. Ich bin mehr als glücklich, meine Nachteile Profis Erfahrung zu teilen.

Oh, und ich habe vergessen, eine Mapping-Strategie ist eine Recherche wert. Ich persönlich mache meine eigenen Zuordnungen, aber diese Logik an einem Ort zu haben, ist von unschätzbarem Wert.

EDIT: Sehr naives Beispiel

ContactViewModel{

    string Name {get;}
    string LastName {get;}
    List<Country> AvailableCountries {get;}
    Country Country {get;}
    bool IsAdmin {get;}

}

ContactBindingModel{

    string Name {get;set;}
    string LastName {get;set;}
    int Country {get;set;}

}

ContactResourceModel{

    string Name { get;set;}
    string LastName {get;set;}
    Country Country {get;set;}
    string IsAdmin {get;}

}
33
Bart Calixto

Wenn Sie versuchen, ein REST basiertes System zu erstellen, kann der Begriff ViewModel und View sehr nützlich sein. Sie können den Begriff Resource ViewModel und die Darstellung View ziemlich genau zuordnen.

Wenn Sie für einen Moment darüber nachdenken, wie eine Ansicht auf einer MVC-Site aussieht. Es ist ein HTML-Dokument. Ein Dokument, das eine Reihe von semantischen Informationen, Titel, Text, Abschnitte, Absätze, Tabellen usw. enthält. Es darf keine "Stil" -Informationen enthalten. Das ist die Aufgabe des Webbrowsers und von CSS. Die Leute sind verwirrt, wenn sie sich HTML als Benutzeroberfläche vorstellen. Es soll nicht die Benutzeroberfläche sein, es ist der Inhalt der Benutzeroberfläche.

Ansichten sind nur eine konkrete Umsetzung des Inhalts des Ansichtsmodells unter Verwendung eines Medientyps, der über das Netzwerk übertragen werden kann. Was dieser Medientyp ist, hängt davon ab, welchen Client Sie zufrieden stellen möchten.

8
Darrel Miller

Wir arbeiten derzeit an einem ähnlichen Projekt, das ASP.Net MVC und ASP.Net Web Api verwendet.

Wir verwenden ASP.Net MVC, um die globale Struktur unserer Seiten zu generieren. Anschließend ruft unsere MVVM-JavaScript-Implementierung die Web-API auf, um die zurückgegebenen Daten in Client-Ansichtsmodelle einzufügen. Zu diesem Zweck gibt unser API ein Ansichtsmodell zurück, das dem entspricht, auf das das Front-End wartet.

Ich denke, dass Ihre API-Ansichtsmodelle von MVC ViewModels abweichen würden (die aus MVVM-Sicht keine ViewModels sind).

Es hängt auch von Ihrer Nutzung von api ab. Beispielsweise müssen Sie bei einer internen Verwendung nicht immer vermeiden, Ihr Domain-Modell anzuzeigen. So vermeiden Sie, das Modell im ViewModel zuzuordnen und die Leistung zu steigern. Für den Fall, dass Sie einige Eigenschaften in Ihren Modellen transformieren müssen, hilft Ihnen viewModels sehr dabei, Ihren Code lose miteinander zu strukturieren.

Da es in webapi keine Views gibt, ist es meines Erachtens nicht sinnvoll, ein ViewModel als Parameter zu haben.

Ich würde sagen, Ihre API wird von Ihren Ansichten am Ende konsumiert, es macht Sinn, ViewModel zu haben.

Spuckt die MVC-Site nur einfache Ansichten zurück und rufen Sie Ihre Webapi dann mit Jquery auf, oder rufen Sie nur MVC-Aktionsmethoden auf, die direkt dieselben Methoden aufrufen, die die Webapi aufrufen würde?

Hier ist es nur eine Frage der Wahl. Sie können MVC action aufrufen, um generierte Ansichten (in HTML) zu erhalten, oder Sie können WebApi aufrufen, um JSON/XML-Antworten zu erhalten, die Sie dann in Ihren Ansichten mit Ihrem Javascript-Code verknüpfen.

3
Julien

Um nur das hinzuzufügen, was andere gesagt haben, ist die Verwendung eines ViewModel, wie es normalerweise genannt wird, auch für die Validierung nützlich. Sie können Ihre Klassen mit Datenanmerkungen versehen, einschließlich aller Validierungsanforderungen. In Ihren Controller-Aktionen können Sie weiterhin ModelState verwenden, um die Validierung zu erzwingen und entsprechende Nachrichten über HttpRequestException oder nur HttpResponseMessage zurückzugeben.

1