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, die zur Interaktion mit der Datenbank verwendet werden, im Modell implementiert sind .

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

Offensichtlich ist die Ansicht keine gute Idee, da dieses Modul der Präsentation gewidmet ist. Der 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?

Das Modell ist nicht auf die Interaktion mit der Datenbank beschränkt, sondern 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. Deshalb sollten Sie dies im Modell tun.

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

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

Eine öffentliche Methode in Ihrem Modell kann wie folgt aufgebaut sein (Pseudocode), der 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);
}

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

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

In der ursprünglichen Desktop-GUI-Definition von MVC handelte es sich um Module . In der Regel gab es in einer Anwendung mehrere, manchmal in Drillingen, manchmal mit einer Vielzahl von Ansichten und Modellen, die von einigen Controllern gemischt und abgeglichen werden konnten.

In Web-Frameworks (OTOH) werden sie in der Regel als Ebenen betrachtet , in denen sie jeweils nur eine sind. Dabei geht es hauptsächlich um die Abdeckung einer untergeordneten Abstraktionsebene: "Die Modellebene abstrahiert die Datenbank", "Die Ansichtsebene implementiert die Präsentation" und "Der Controller" Ebene verarbeitet Benutzereingaben ".

Ich würde also sagen, dass Sie bereits ein Modell für die Interaktion mit der Datenbank haben und jetzt nur noch 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 View-Codes nahtlos mit beiden Modellen zusammenarbeiten.

Ein Teil der Schwierigkeit bei jeder Diskussion über MVC besteht darin, dass verschiedene Gruppen sich dafür entschieden haben, unterschiedliche Bedeutungen zu haben. 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, handelt es sich eher um eine Reihe von Leitprinzipien (trennen Sie die Kernanwendung von ihrer visuellen Darstellung, stellen Sie flexible Mechanismen zur Verfügung, mit denen beide zusammenarbeiten können), die in verschiedenen Varianten implementiert werden können Wege.

In der Tat gibt es die Tendenz, verschiedenen MVC-abgeleiteten Designs unterschiedliche Namen zu geben (siehe diesen Artikel von Martin Fowler für eine Diskussion darüber) oder sogar auf eine präzise Benennung zu verzichten - zum Beispiel beschreibt sich AngularJS selbst als Model-View-Whatever Rahmen.

Daher ist es schwierig zu antworten, 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), die in vielen Implementierungen vollständig im Modell enthalten ist.

Hier wird das Modell folgendermaßen beschrieben:

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

Ich würde sagen, dass der Controller entweder die Logik zum Aufrufen des Dienstes enthält oder ein separates ServiceObjekt aufruft . Wenn der Dienst separat ist, können Sie einfacher Tests erstellen, z. B. wenn keine Verbindung zu einem Dienst über ein Netzwerk möglich ist, können einige lokal TestServiceantworten Service.

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

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

Ihr Controller sollte für die Kontaktaufnahme mit APIs, Datenbanken, Diensten usw. verantwortlich sein, 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 haben Sie jetzt die Garantie, dass nur Code im Controller Nebenwirkungen hervorrufen 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.

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

Ich würde es zu einer Klasse (dh einer Bibliothek von Methoden zur Datenreduzierung) anstatt zu einem Modell (dh einem Stapel von Funktionen zur Datenreduzierung) 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.