1. Die Frage neu formulieren
In Ihrem Beispiel wird vorgeschlagen, dass die Daten auf der Drupal-Seite schreibgeschützt sind und nur in eine Richtung synchronisiert werden. Ich denke, dies ist der wichtigste Faktor, der hier berücksichtigt werden muss, da jede von Ihnen implementierte Lösung eine Variante von Remotespeicherung, Synchronisierung und lokalem Caching darstellt - selbst wenn das lokale Caching letztendlich Entitäten in der Drupal-Datenbank sind.
Die Frage lautet also, anstatt "lokaler Speicher gegen Remote-Speicher" zu sein:
- Sollten Sie die Daten überhaupt lokal zwischenspeichern;
- Sollten Sie die Daten als tatsächliche Entitäten zwischenspeichern und Feeds (oder ähnliches) verwenden, um die Daten regelmäßig zu synchronisieren; ODER
- Sollten Sie ein maßgeschneidertes Modul verwenden, das die Synchronisierung und das Caching ermöglicht.
Ein Artikel, der Sie interessieren könnte, ist " Remote Entities in Drupal 7 ".
2. Zwischenspeichern der Daten
Im Allgemeinen ist das Zwischenspeichern der Daten eine gute Idee:
Sie sind vor Ausfällen der anderen Dienste oder Zeitüberschreitungen in der Verbindung geschützt.
Wenn Ihre Daten in Ihrer Drupal-Datenbank vorhanden sind, wird der Betrieb beschleunigt.
Wenn Ihre Daten in Ihrer Drupal-Datenbank vorhanden sind, ist die Wahrscheinlichkeit höher, dass Sie in andere Module wie Ansichten integriert werden (dies ist jedoch nicht garantiert).
Der einzige Vorteil, wenn die Daten nicht zwischengespeichert werden, besteht darin, dass Sie niemals veraltete Daten erhalten, was in einigen Fällen vorzuziehen ist. Manchmal ist es vorzuziehen, keine Daten anstelle veralteter Daten anzuzeigen. Ich sehe dies in dem von Ihnen angegebenen Beispiel nicht als Vorteil an, daher werde ich diese Antwort auf eine Lösung konzentrieren, die lokales Caching umfasst.
3. Lokale Entitäten + Synchronisierung
Wenn Sie sich für die Option entscheiden, lokale Entitäten zu haben und diese selbst zu synchronisieren, kehren wir zu Ihren ursprünglichen Fragen zurück:
3.1 Knoten gegen benutzerdefinierte Entitäten
Die Definition, was genau ein Knoten ist, ist ziemlich offen. Auf der Dokumentationsseite zu Knoten wird vorgeschlagen , dass Knoten "Beiträge" veröffentlichen, die auf Ihrer Site "gespeichert" sind - beides gilt nicht für Ihre Daten.
Als Drupal-Entwickler würde ich erwarten, dass wenn etwas ein Knoten ist, ich es auf der Site selbst manipulieren kann;
Als Drupal-Benutzer würde ich ebenfalls erwarten, dass Knoten bearbeitet werden können.
Diese Drupal 8-Ausgabe https://drupal.org/node/2019031 legt nahe, dass das Konzept "schreibgeschützt" eher auf Entitätsebene als auf Bundle-Ebene gilt. Sollte dies jemals umgesetzt werden, würden Sie davon profitieren, wenn Sie diesen Weg gegangen wären.
Zusammenfassend lässt sich sagen, dass Ihre Daten schreibgeschützt sind und remote gespeichert werden. Es ist sinnvoller, einen benutzerdefinierten Entitätstyp zur Darstellung Ihrer Daten zu verwenden.
3.2 Synchronisieren
Für den zweiten Teil sind die beiden Hauptmodule hierfür, wie Sie vorschlagen, Feeds und Migrate .
Der Unterschied zwischen Feeds und Migrate besteht darin, dass Feeds für den regelmäßigen Import von Inhalten erstellt werden, während Migrate für die einmalige Portierung von Inhalten von einem Ort zum anderen erstellt wird. Migrate unterstützt die Aktualisierung vorhandener Daten. Da jedoch beide Module gut unterstützt werden, ist es sinnvoller, das Modul zu verwenden, das für die jeweilige Aufgabe erstellt wurde. Feeds passen besser zusammen.
Nachdem ich beide Module selbst verwendet habe (Feeds für die Synchronisierung, Migration für die Migration), finde ich Feeds nicht unordentlicher als Migrate. Nach meiner Erfahrung war für die Migration mehr benutzerdefinierter Code erforderlich. Die Migration ganzer Websites ist jedoch komplexer als der Import einzelner Inhaltstypen, sodass ein Vergleich schwierig ist.
4. Benutzerdefiniertes Modul für Remote-Speicher, Synchronisierung + Caching
Es gibt eine Reihe von Modulen, die bei dieser Aufgabe helfen können.
Sie haben das Web Services-Datenmodul erwähnt , und andere haben das Datenmodul erwähnt . Eine weitere zu berücksichtigende Option ist das Remote Entity API-Modul . Beachten Sie, dass das einzige, mit dem ich Erfahrung habe, das Datenmodul ist.
Das Web Services Data-Modul verfügt noch nicht über eine Version. Dies kann darauf hinweisen, dass der Code noch nicht stabil ist, die API möglicherweise geändert wird usw. Entitätsfeldabfragen werden nicht unterstützt (gemäß der Projektseite), und ein schnelles Durchsuchen des Code-Repositorys zeigt keine Hinweise darauf, dass Ansichten unterstützt werden. Sie können also keine Ansichten zum Anzeigen Ihrer Entitäten verwenden.
Das Datenmodul richtet sich meiner Erfahrung nach eher an Nicht-Entwickler, die Daten in einer Tabelle haben und diese Ansichten anzeigen möchten. Ich habe festgestellt, dass die Verwendung der Drupal 6-Version ziemlich frustrierend ist - obwohl sich dies seitdem möglicherweise geändert hat.
Das Remote Entity API-Modul klingt vielversprechend - es unterstützt das Abrufen und Zwischenspeichern von Remote Entities und unterstützt Views. Es ist nur auf Alpha-Version - daher kann sich die API noch ändern. Auf den ersten Blick scheint es auch keine Unterstützung für Entity Field Query zu geben, und es wird nur eine Art von Remote-Service unterstützt, sodass Sie Ihren eigenen implementieren müssten.
Fazit
Da keines der Remotespeichermodule Entitätsfeldabfragen unterstützt, ist die Verwendung tatsächlicher Entitäten + Feeds die Lösung, mit der Sie die beste Integration in Ihre Drupal-Site erzielen.
Wenn die Unterstützung von Ansichten ausreicht und Sie sich keine Sorgen über eine mögliche Integration mit anderen Modulen über Entitätsfeldabfragen machen, ist die Verwendung der Remote-Entitäts-API möglicherweise der richtige Weg. Sie müssten jedoch Ihre eigene Remote-Schnittstelle implementieren.