it-swarm.com.de

MVC- und RESTful-API-Service

MVC ist ziemlich einfach. Es gibt ein Modell, einen Controller und eine Ansicht. Wenn wir eine Website erstellen, wird alles zusammengeführt als 'Client sendet REST Schlüsselwortanforderung an Server -> der Server stimmt die angeforderte URL mit der Controller-Aktion überein -> die dann die aufruft Modell (e) für die Datenerfassung/-verarbeitung, erhält das Ergebnis -> und gibt das Ergebnis als HTML-Seite (Ansicht 'an den Client zurück.

Was ist, wenn es sich um einen reinen RESTful API-Webdienst handelt? Dann ist der Ablauf so etwas wie 'Client sendet REST Schlüsselwortanforderung an Server -> der Server stimmt die angeforderte URL mit der Controller-Aktion überein -> die dann die Modelle aufruft) Für die Datenerfassung/-verarbeitung wird das Ergebnis abgerufen -> und das Ergebnis in JSON an den Client zurückgegeben. '. Wie zuvor, aber es gibt keine' Ansicht '... oder besser gesagt, der generierte JSON kann gedacht werden In gewisser Weise verwenden wir nur den MC-Teil von MVC. Ist dies der Fall? Oder gibt es andere, besser geeignete Muster für einen Nur-API-Dienst anstelle von MVC?

12
simon

MVC ist ein Paradigma aus der Smalltalk-Welt, das sich mit der Frage befasst, wie objektorientierte Systeme Benutzeroberflächen haben könnten.

Frühe Web-Frameworks nahmen die allgemeine Idee (trennen Geschäftslogik, Steuerlogik und Ansichtslogik) und wandten das Prinzip auf die Strukturierung der Webanwendung an. Vorher war es nicht ungewöhnlich, dass Gott schrecklichen Code von HTML-Generierungscode in Domänenobjekten oder Geschäftslogik in HTML-Vorlagen durcheinander brachte (denken Sie an sehr frühes PHP).

Die Sache ist, dass die ursprüngliche MVC aus der Smalltalk-Welt nicht wirklich das ist, was MVC in den meisten Web-Frameworks ist. Eine HTML-Ausgabe ist nicht wirklich eine "Ansicht" in dem Sinne, wie Smalltalk einen UI-Bildschirm verstanden hat.

Das ist also der erste Grund, sich nicht zu sehr darauf einzulassen, ob Sie MVC richtig folgen. Kaum etwas ist. Nehmen Sie es weniger als strenge Unterteilung als vielmehr als Richtlinie für Hey, wäre es nicht schön, wenn unsere HTML-Vorlagen nicht voller Geschäftslogik wären.

Zweitens ist MVC nur eine Möglichkeit, serverseitigen Code zu strukturieren. Es hat wirklich nichts mit REST/HTTP zu tun. REST befasst sich mit der Kommunikation zwischen Clients und Servern. Es ist egal, ob sich die Darstellung, die der Server an den Client sendet, in einer HTML-Vorlage befindet, deren Erstellung mit einer Template-Engine viel Zeit in Anspruch genommen hat, oder Ein JSON-Objekt, das ein Aufruf im Controller war.

Wenn Sie nicht glauben, dass Ihr Server eine "Ansicht" -Ebene benötigt, ist dies in Ordnung. Sie profitieren weiterhin davon, wenn Sie Ihre Geschäftslogik (dh Ihr Modell) von den Controllern trennen, die eine bestimmte HTTP-Anforderung verarbeiten, selbst wenn alle Controller einen JSON-Parsing-Aufruf für ein Objekt aufrufen und diese Daten zurückgeben.

21
Cormac Mulhall

Ansicht ist eine Ebene, die für die Anzeige von Informationen verantwortlich ist, die von einem Benutzer/Client Ihrer Anwendung interpretiert werden können (dies bedeutet nicht, dass der Benutzer eine tatsächliche Person sein muss). JSON ist ein vollständig gültiges Format für eine Ansichtsebene. Computer verstehen das.

Solange die Ansichtsebene Informationen veröffentlicht, die von einem Benutzer verwendet werden können, um Modelle in Ihrer Anwendung zu beeinflussen, spielt es keine Rolle, wie die Ansicht aussieht. Es handelt sich dennoch um eine Ansicht, eine Ebene, die als Middleware zwischen dem Benutzer und dem System fungiert .

9
Andy

MVC ist ziemlich einfach.

Martin Fowler würde vielleicht nicht damit einverstanden sein :

Verschiedene Leute, die an verschiedenen Orten über MVC lesen, nehmen unterschiedliche Ideen davon und beschreiben diese als "MVC".

Weitermachen ...

Wenn wir eine Website erstellen, wird alles zusammengeführt, wenn 'Client REST Schlüsselwortanforderung an Server sendet -> der Server stimmt die angeforderte URL mit der Controller-Aktion überein -> die dann die Modelle aufruft) Für die Datenerfassung/-verarbeitung wird das Ergebnis abgerufen -> und das Ergebnis als HTML-Seite (Ansicht) an den Client zurückgegeben.

OK, das ist ein bisschen verwickelt

MVC ist eine Sammlung von Ideen zur Implementierung von Benutzeroberflächen.

REST ist eine Sammlung von architektonischen Einschränkungen für die Erstellung umfangreicher Anwendungen.

Das Web, von dem Sie hier sprechen, ist eine riesige Dokumentenverwaltungsanwendung, die unter Verwendung der meisten dieser Einschränkungen erstellt wurde.

Die Ähnlichkeiten, die Sie zwischen den beiden sehen, werden (treffen Sie Ihre Wahl) falsch zugeschrieben oder oberflächlich.

RESTafarians haben ein gemeinsames Verständnis von HASSOAS , "Hypertext als Motor des Anwendungsstatus", und das sollte Alarme durch Sie klingeln lassen head - warum sollte eine Ansicht eine Engine mit dem Status sein? Wenn wir die Prämisse in Frage stellen und nach zusätzlichen Beweisen suchen, können wir auch zwei seltsame Dinge bemerken.

Erstens, dass wir den HTTP-Server vollständig aus der Gleichung herausnehmen können, indem wir den HTML-Code von der Festplatte laden. Der Browser ist damit vollkommen zufrieden und entschuldigt einige geringfügige Abweichungen im Verhalten, die sich aus der Änderung der Basis-URL ergeben können. Ansichten funktionieren im Allgemeinen nicht weiter, wenn sie vollständig vom Modell und vom Controller getrennt wurden.

Zweitens, wenn wir einen modernen Browser sorgfältig beobachten, werden wir feststellen, dass es mehrere Ansichten des HTML gibt. Mehrere Ansichten einer Ansicht scheinen eine wirklich seltsame Idee zu sein, aber es gibt sicher die Hauptpräsentation mit einer Reihe von Textmarkierungen, die auf Benutzergesten reagieren, und dann gibt es diese "Quellansicht", die den rohen HTML-Code anzeigt und auch darauf reagiert Benutzergesten. Es sind Schildkröten ganz unten!

Die Antwort auf das Rätsel ist natürlich, dass der HTML-Code nicht die Ansicht ist. Die Sammlung von Widgets im Browser ist die Ansicht und steht in Verbindung mit dem Dokumentobjektmodell , das durch Lesen des HTML-Codes initialisiert wurde.

Mit anderen Worten, der HTML-Code ist eine Darstellung des Zustands, genau wie Roy T. Fielding versprochen.

Was ist, wenn es sich um einen reinen RESTful API-Webdienst handelt? Wie zuvor, aber es gibt keine "Ansicht"

Richtiger wie zuvor: Es gibt keine Sicht. Der JSON ist genau wie der HTML-Code eine Darstellung des Zustands, die zum Überschreiten von Prozessgrenzen geeignet ist.

Denken Sie an "DTO" oder "Nachricht", und Ihre Schlussfolgerungen führen Sie viel seltener in die Irre.

2
VoiceOfUnreason

Ist es so, wie es gemacht werden soll?

Wenn Sie JSON als Ansicht übergeben oder als Ansichtsmodell zum Erstellen der Ansicht verwenden, wird das Muster nicht verletzt.

Ich verwende dieselbe Architektur in der aktuellen Anwendung, an der ich arbeite, und sie funktioniert sehr gut. Zusammen mit einem Nice JS-Framework können Sie einige wirklich reaktionsschnelle Designs erstellen.

Oder gibt es andere, besser geeignete Muster für einen Nur-API-Dienst anstelle von MVC?

Ehrlich gesagt keine Ahnung. Aber ich denke, dass es nicht so wichtig ist, ob Sie MVC in einer API verwenden oder nicht. Verwenden Sie alles, was Sie für bequem halten. Wenn über Webdienste gesprochen wird, müssen viel wichtigere Aspekte berücksichtigt werden (die nicht direkt mit MVC zusammenhängen), z. Sicherheit, Konsistenz, Verfügbarkeit usw.

1
djvuk