it-swarm.com.de

Wo soll ich eine API-Anfrage in MVC stellen?

Ich erstelle eine Webanwendung mit einem MVC-Muster. Nach dieser Art von Architektur können wir sehen, dass alle Methoden zur Interaktion mit der Datenbank im Modell implementiert sind.

Aber was passiert, wenn ich einen Dienst anrufen muss, der von anderen im Web verfügbar gemacht wird? Zum Beispiel möchte ich auf die Facebook-API zugreifen, um alle Follower meiner Seite zu erhalten. Wo platziere ich diese Methoden?

Offensichtlich ist das Ansicht keine gute Idee, da dieses Modul der Präsentation gewidmet ist. Das Controller sollte nicht zum Abrufen von Daten verwendet werden, sondern das Modell ist normalerweise nur der Interaktion mit der Datenbank gewidmet.

Können Sie mir einen Hinweis dazu geben? Und bitte, können Sie mir sagen, ob ich Fehler in Bezug auf die MVC-Architektur mache?

25
Ema.jar

Das Modell ist nicht auf die Interaktion mit der Datenbank beschränkt, sondern ist für das Abrufen und Bearbeiten von Daten verantwortlich.

Für Ihre Ansicht und Ihren Controller sollte es also keinen Unterschied machen, ob die Daten aus einer Datenbank oder einem Webservice stammen oder sogar völlig zufällig sind. Daher sollten Sie dies im Modell tun.

MVC ist ein Präsentationsmuster, das nur die verschiedenen Darstellungsebenen trennt.

Dies bedeutet nicht, dass das Modell ein einheitliches Durcheinander von Spaghetti-Code sein muss. Ihr Modell selbst kann ebenfalls geschichtet werden, aber der Controller sollte nicht wissen, woher die Daten stammen.

Eine öffentliche Methode in Ihrem Modell kann wie folgt aufgebaut sein (Pseudocode), die von Ihrem Controller aufgerufen werden kann:

public MyDataClass getData(int id) {
    WebServiceData wsData = WebService->getData(id);
    DatabaseData dbData = ORM->getData(id);
    return new MyDataClass(wsData, dbData);
}

WebService und ORM müssen möglicherweise Instanzen von Schnittstellen sein, die durch Abhängigkeitsinjektion durch Mocks ersetzt werden können, aber Ihre Controller und Ansichten müssen sich zu Testzwecken nicht ändern.

37
Residuum

Es gibt ein häufiges (absichtliches?) Missverständnis darüber, was M, V und C sind. Nicht über die Rollen, die sie einnehmen, sondern was sind sie.

In der ursprünglichen Desktop-GUI-Definition von MVC waren sie Module. In der Regel hatte eine Anwendung mehrere davon, manchmal in Drillingen, manchmal mit einer Vielzahl von Ansichten und Modellen, die einige Controller mischen und anpassen konnten.

In Web-Frameworks, OTOH, werden sie in der Regel als Ebenen angesehen, wobei sie jeweils nur eine sind und sich hauptsächlich mit der Abdeckung einer untergeordneten Abstraktionsebene befassen: "Die Modellebene abstrahiert die Datenbank", "die Ansichtsebene" implementiert Präsentation "," die Controller-Schicht verarbeitet Benutzereingaben ".

Ich würde also sagen, dass Sie bereits ein a Modell haben, das der Interaktion mit der Datenbank gewidmet ist, und jetzt nur noch ein ein anderes Modell erstellen müssen, um mit Ihrer Quell-API fertig zu werden. Wenn Sie sie so ähnlich wie möglich gestalten, können die meisten Controller- und Ansichtscodes nahtlos mit beiden Modellen zusammenarbeiten.

12
Javier

Ein Teil der Schwierigkeit bei jeder Diskussion über MVC besteht darin, dass verschiedene Gruppen es so gewählt haben, dass es unterschiedliche Bedeutungen hat. Die Implementierung von MVC, die beispielsweise in einer Rails App) verwendet wird, ist für jemanden, der eine Swing-App schreibt, fast nicht wiederzuerkennen. In dem Maße, in dem MVC immer noch eine genau definierte Sache ist, ist es eher eine Eine Reihe von Leitprinzipien (trennen Sie die Kernanwendung von ihrer visuellen Darstellung, stellen Sie flexible Mechanismen bereit, damit beide zusammengelegt werden können), die auf verschiedene Arten implementiert werden können.

In der Tat besteht die Tendenz, verschiedenen von MVC abgeleiteten Designs unterschiedliche Namen zu geben (siehe dieser Artikel von Martin Fowler für eine Diskussion darüber) oder sogar die genaue Benennung aufzugeben - zum Beispiel beschreibt sich AngularJS selbst als Model-View-Whatever-Framework.

Es ist daher schwer zu beantworten, ohne zu wissen, mit welcher Version von "MVC" Sie arbeiten. Eine API-Anforderung ist jedoch normalerweise Teil der Kernanwendung (der Teil, der sich nicht ändern sollte, wenn Sie sich für eine andere visuelle Darstellung entscheiden), der in vielen Implementierungen vollständig im Modell enthalten ist.

5
James_pic

hier , das Modell wird folgendermaßen beschrieben:

Ein Modell speichert Daten, die an die Steuerung abgerufen und in der Ansicht angezeigt werden. Bei jeder Änderung der Daten werden diese vom Controller aktualisiert.

Ich würde sagen, dass der Controller entweder die Logik zum Aufrufen des Dienstes enthält oder ein separates Service -Objekt aufruft. Wenn der Dienst separat ist, können Sie einfacher Tests erstellen. Wenn beispielsweise keine Verbindung zu einem Dienst über ein Netzwerk möglich ist, können einige TestService lokal Antworten von Service bereitstellen.

Lesen Sie auch diese Antwort, die darauf hindeutet, dass der Controller den Dienst aufruft.

2
null

Ihr Modell sollte niemals tatsächlichen Code enthalten und eher als Nachricht oder Struktur angesehen werden, die zum Verwalten von Inhalten verwendet wird, die vom Controller manipuliert und von der Ansicht angezeigt werden.

Ihr Controller sollte dafür verantwortlich sein, APIs, Datenbanken, Dienste usw. zu kontaktieren, um eine Änderung anzufordern und alle erforderlichen Aktualisierungen des Modells zu verwalten.

Die gesamte Stärke des MVC-Musters besteht darin, dass es die Logik (den Controller) von der Ansicht und dem Status (dem Modell) entkoppelt. Auf diese Weise wird Ihnen jetzt garantiert, dass nur Code im Controller Nebenwirkungen verursachen kann, da die Ansicht und das Modell einfach keine Änderungen vornehmen dürfen.

Es ermöglicht auch eine bessere Wiederverwendung von Code, da ein Modell von verschiedenen Controllern und Ansichten gemeinsam genutzt werden kann.

2
CLW

Könnte hier weit weg sein, aber so empfinde ich WebApps und die Arbeit mit [komplexen] Remote-APIs in vielen Fällen:

Ich würde es zu einer Klasse (dh einer Bibliothek von Datenminderungsmethoden) anstelle eines Modells (dh einem Stapel von Datenminderungsfunktionen) machen. Es scheint, als würde es transparenter, logischer/schemaunabhängiger wirken, und Sie könnten es überall verwenden, ohne jedes Mal, wenn Sie es verwenden möchten, ein Modell/einen Controller selbst aufzurufen. Die Logik ist immer noch getrennt, der Datenpunkt ist immer noch flexibel und es scheint offener für Interoperabilität in seltsamen Fällen wie dem Stapeln von clientAJAX-> appJSON-> appLIB-> remoteAPI-> remoteJSON usw., um den Endpunkt indirekt abzufragen.

1
dhaupin