Nach meinem Codierungsstil (und Verständnis von MVC) würden externe Anrufe in ein "tableless" -Modell platziert werden. RailsCasts 193 spricht ein wenig über dieses Konzept, und eine weniger klobige Syntax wird in Rails 4 unterstützt. Wenn es nötig ist Haben Sie irgendeine Manipulation des Codes, scheint das Modell der logische Ort, um diese zu platzieren. Das Verschieben dieser Methoden in den Controller würde zwar funktionieren, könnte aber bei wachsender App Probleme verursachen.
Eine weitere Überlegung bei externen API-Aufrufen besteht darin, diese in einer Datenbank zu speichern, die zu diesem Zeitpunkt definitiv in einem Modell enthalten sein sollte. Daher wird (für mich) klarer, dass diese wirklich im Modell enthalten sein sollten.
API-Aufrufe an externe Dienste (Drittanbieter) sind nicht spezifisch für Ihre App, da deren Dienst für alle (theoretisch) verfügbar ist. Ich gehe davon aus, dass diese Art von Features im Verzeichnis lib/ enthalten sind, da sie nicht für die App spezifisch sind. Im Idealfall könnten Sie dann den Code aus Ihrem lib in Ihrem Projekt herausziehen und ihn in einem anderen Projekt in einem anderen Projekt lib/ einfügen und es würde immer noch gut funktionieren.
Versetzen Sie den Aufruf in lib/ . Wenn Sie möchten, können Sie das Modell aus den zurückgegebenen Daten in Ihrem Controller erstellen.
Es würde ungefähr so aussehen:
app / controller /
%Vor%lib /
%Vor%Sehr spät zu diesem, aber ich dachte, ich würde meine 2p / 2c hinzufügen.
Ich möchte versuchen, meine Controller von irgendetwas abgesehen von Controller-Code sauber zu halten, den ich lose als Programmflusscode basierend auf Anforderungstyp und Parametern definiere. Wählen Sie beispielsweise die richtige Vorlage für den Anforderungstyp aus oder wählen Sie die richtige Methode zum Aufrufen aus, je nachdem, ob ein Benutzer angemeldet ist oder nicht.
Wenn es darum geht, die Antworten zu berechnen, mag ich es nicht, den Controller mit viel Code zu bestreuen, der Modelle manipuliert und Instanzparameter setzt. Dies ist schwer zu testen und noch schwieriger zu verwenden. Ich ziehe es vor, auf ein anderes Objekt zu verweisen und ein einzelnes Wertobjekt an die Vorlage zurückzugeben.
Manchmal kann ich auf ein Modell verzichten: Vielleicht ist es ein einfaches Nachschlagen und ich sende nur ein einzelnes Modell an die Vorlage oder eine Reihe von Modellen.
Vielleicht habe ich eine nützliche Methode in einem Modell implementiert, um ein entsprechendes Wert- oder Wertobjekt zurückzugeben.
Aber manchmal mache ich etwas, das kein Modell verwendet, oder das mehrere Modelle verwendet, oder das nicht das Gefühl hat, dass es das Modell verstopfen sollte. In diesem Fall ist weder der Controller noch ein Modell ein geeigneter Ort für den Code.
Das lib-Verzeichnis fühlt sich auch nicht richtig an. Ich tendiere dazu, das lib-Verzeichnis als irgendwo zu behandeln, das Code enthält, den ich noch nicht in Edelsteine verwandelt habe. Wenn der Code, den ich schreibe, nur im Kontext der Anwendung Sinn macht, ist es nicht gut.
Also wende ich mich Service-Objekten zu. Unter dem Ordner "app" habe ich einen Ordner "services", der kleine funktionale Klassen enthält, die einzelne Bereiche des Site-Verhaltens einkapseln. (Oder koordinieren Sie manchmal mehrere andere Dienste, um eine einfache Schnittstelle für den Controller bereitzustellen.)
Dadurch kann ich meine Controller und meine Modelle schlanker machen und ist ein perfekter Ort, um Code zu platzieren, der eine API kontaktieren muss.
Wenn Sie einen Schritt weiter gehen wollten, könnten Sie die API selbst in eine Wrapper-Klasse (oder eine Gruppe von Klassen) einfügen und diese im lib-Verzeichnis behalten (für die spätere Umwandlung in ein Juwel). Dann würde das Service-Objekt die Aufgabe ausführen, den API-Wrapper mit den entsprechenden Werten aufzurufen (vom Controller übergeben) und mit etwas zu antworten, das eine Vorlage sauber abfragen kann.
Natürlich können Sie noch weiter gehen und weitere Ebenen hinzufügen. Beispielsweise könnte eine Darstellungsschicht zwischen dem Dienstobjekt (das generische Werte bereitstellt) und Formatdaten für eine bestimmte Ansicht liegen. (Vielleicht möchten Sie sowohl eine Webseite als auch einen RSS-Feed bereitstellen, und sie benötigen beispielsweise unterschiedliche Datumsformate.)
Aber Sie bekommen die Idee.
Tags und Links ruby-on-rails api