1. Переформулировать вопрос
Ваш пример показывает, что данные читаются только на стороне Drupal, только с односторонней синхронизацией. Я думаю, что это самый важный фактор, который следует учитывать здесь, потому что, по сути, любое решение, которое вы реализуете, будет вариантом удаленного хранения, синхронизации и локального кэширования - даже если локальное кэширование в конечном итоге станет сущностью в базе данных Drupal.
Таким образом, вопрос, а не «локальное хранилище против удаленного хранилища» будет:
- Если вы вообще кешируете данные локально;
- Если вы кешируете данные как фактические объекты и используете каналы (или аналогичные) для регулярной синхронизации данных; ИЛИ
- Если вы используете какой-то специальный модуль, который обеспечивает синхронизацию и кэширование.
Вас может заинтересовать статья « Удаленные сущности в Drupal 7 ».
2. Кеширование данных
В общем, кэширование данных является хорошей идеей:
Вы защищены от перебоев в работе других служб или тайм-аутов в соединении;
Наличие ваших данных в вашей базе данных Drupal ускорит операции;
Наличие ваших данных в базе данных Drupal будет означать, что вы с большей вероятностью получите интеграцию с другими модулями, такими как Views (хотя это не гарантируется).
Единственное преимущество отсутствия кэширования данных состоит в том, что вы никогда не получите устаревшие данные, что в некоторых случаях предпочтительнее - иногда предпочтительнее не отображать данные, а не устаревшие данные. Я не рассматриваю это как преимущество в приведенном вами примере, поэтому я сосредоточу этот ответ на решении, которое включает локальное кэширование.
3. Локальные объекты + Синхронизация
Если вы выберете локальные объекты и синхронизируете их самостоятельно, мы вернемся к вашим первоначальным вопросам:
3.1 Узлы против пользовательских объектов
Определение того, что именно является узлом, является достаточно открытым. Страница документации по узлам предполагает, что узлы «публикуют», которые «хранятся» на вашем сайте - ни один из них не применим к вашим данным;
Как разработчик Drupal, я ожидал бы, что если что-то будет узлом, я смогу манипулировать им на самом сайте;
Как пользователь Drupal, я бы также ожидал, что узлы можно редактировать;
В этом выпуске Drupal 8, https://drupal.org/node/2019031, предполагается, что концепция «только для чтения» применима на уровне сущностей, а не на уровне пакетов. Если это когда-либо будет реализовано, вы выиграете, пройдя этот путь.
Подводя итог: ваши данные доступны только для чтения и хранятся удаленно, поэтому имеет больше смысла использовать пользовательский тип объекта для представления ваших данных.
3.2 Синхронизация
Для второй части, как вы предлагаете, два основных модуля для этого - Feeds и Migrate .
Разница между Feeds и Migrate заключается в том, что Feeds предназначен для регулярного импорта контента, а Migrate - для одноразового переноса контента из одного места в другое. Migrate поддерживает обновление существующих данных, однако, учитывая, что оба модуля хорошо поддерживаются, имеет смысл использовать модуль, созданный для поставленной задачи, - Feeds - лучшее соответствие.
Используя оба модуля самостоятельно (каналы для синхронизации, миграция для миграции), я не нахожу каналы более грязными, чем миграция. По моему опыту, для миграции требовалось больше пользовательского кода, хотя миграция целых сайтов сложнее, чем импорт отдельных типов контента, поэтому сравнивать сложно.
4. Пользовательский модуль для удаленного хранения, синхронизации + кеширования
Есть ряд модулей, которые могут помочь с этой задачей.
Вы упомянули модуль данных веб-служб , а другие упомянули модуль данных . Другой вариант, который стоит рассмотреть, - это модуль API удаленного объекта . Обратите внимание, что только один из тех, с кем у меня есть опыт, это модуль данных.
У модуля данных веб-сервисов еще нет выпуска - это может указывать на то, что код еще не стабилен, API может измениться и так далее. Он не поддерживает запросы полей сущностей (в соответствии со страницей проекта), и быстрый просмотр хранилища кода не показывает никаких доказательств того, что у него есть поддержка Views - поэтому вы не сможете использовать Views для отображения ваших сущностей;
По моему опыту, модуль данных более ориентирован на тех, кто не является разработчиком, у которого есть данные в таблице, и которые хотят представить их для просмотра. Я обнаружил, что версия Drupal 6 довольно разочаровывает, хотя с тех пор она могла измениться;
Модуль Remote Entity API звучит довольно многообещающе - он поддерживает выборку и кэширование удаленных объектов, а также имеет поддержку Views. Это только на альфа-версии - так что API все еще может измениться. На первый взгляд кажется, что он не поддерживает Entity Field Query, а поддерживает только один тип удаленного сервиса, поэтому вам придется реализовать свой собственный.
Вывод
Учитывая, что ни один из модулей удаленного хранения не поддерживает Entity Field Queries, использование реальных сущностей + фиды - это решение, которое обеспечит вам наилучшую интеграцию с вашим сайтом Drupal.
Если поддержки Views достаточно, и вы не беспокоитесь о потенциальной интеграции с другими модулями через Entity Field Queries, тогда использование Remote Entity API может оказаться подходящим вариантом - вам, однако, потребуется реализовать собственный удаленный интерфейс.