我已经看到了许多在Drupal中集成远程数据结构的策略。随着某些模块的稳定和用例的尝试，该策略似乎在发展。

想象一下，我们有一个“农民市场”数据结构，它由通过REST API公开的许多数据类型（市场，市场时间，供应商，摊位，农产品）表示。外部服务的ID需要在Drupal中关联，即，在加载“市场”时，我们希望从“ market_hours”和“ stall”中获取数据。将其表示为定期同步的Drupal只读内容的最佳方法是什么？

我正在尝试使用以下标准对此进行评估：

Drupal中的数据结构：

节点与自定义实体

我已经看到许多涉及Web服务的场景使用自定义实体。它简化了CRUD操作。但是，这些项目将是“内容”，因为它们将被公开查看。

存储（本地与远程）：

我已经看到了几个将服务作为远程实体加载的示例，该模块为此模块创建了一个库：https : //drupal.org/project/wsdata。这听起来很吸引人，但是还没有看到很多用例。还有自定义代码的示例：https : //drupal.org/sandbox/fago/1493180

同步数据：

Feed，Migrate，Guzzle，“ Web服务客户端”与“ Web服务数据”

有很多选择。Feed现在支持实体。迁移似乎比feed干净得多，尤其是对于自定义场景。我也曾见过人们使用耗时的客户端与远程服务进行同步：http ://drupalcode.org/project/ckan.git/blob/refs/heads/ckan_dgu_7.x-1.x: /ckan.drush。 inc＃l273。我还注意到WS客户端模块https://drupal.org/project/wsclient提供了一个选项，该选项专门作为其他客户端创建的。Web服务数据直接从服务加载并本地缓存。

感谢您的任何想法。

1.重新提出问题

您的示例建议在Drupal端仅读取数据，并且仅进行单向同步。我认为这是这里要考虑的最重要的因素，因为实际上，无论您实现的解决方案是远程存储，同步和本地缓存的变体，即使本地缓存最终成为Drupal数据库中的实体。

因此，问题将不是：“本地存储还是远程存储”：

• 您是否应该完全本地缓存数据；
• 您是否应该将数据缓存为实际实体，并使用Feed（或类似数据）定期同步数据；要么
• 您是否应该使用一些提供同步和缓存的定制模块。

您可能会感兴趣的文章是“ Drupal 7中的远程实体 ”。

2.缓存数据

通常，缓存数据是一个好主意：

• 您可以防止其他服务中断或连接超时；

• 将数据显示在Drupal数据库中将加快操作速度；

• 将数据显示在Drupal数据库中将意味着您更有可能与其他模块（例如视图）集成（尽管不能保证）。

不缓存数据的唯一好处是，您永远不会获得过时的数据，在某些情况下，这是更可取的-有时，不显示任何数据而不是过时的数据更可取。在您提供的示例中，我认为这没有好处，因此，我将把答案集中在涉及本地缓存的解决方案上。

3.本地实体+同步

如果您选择拥有本地实体并自己同步它们，那么我们将回到您的原始问题：

• 您应该使用节点还是自定义实体？

• 哪个模块最适合同步。

3.1节点与自定义实体

• 确切说是一个节点的定义是相当开放的。节点上的文档页面建议节点是“发布”的，这些节点“存储”在您的站点上-都不适用于您的数据；

• 作为Drupal开发人员，我希望如果某个东西是一个节点，那么我应该能够在站点本身上进行操作；

• 作为Drupal的用户，我同样希望可以编辑节点。

• 此Drupal 8问题https://drupal.org/node/2019031建议“只读”的概念适用于实体级别，而不是捆绑包级别。如果实现了这一点，那么您可以从这条路线中受益。

总结一下：您的数据是只读的并且是远程存储的，因此使用自定义实体类型来表示您的数据更有意义。

3.2同步

对于第二部分，正如您所建议的，这两个主要模块是Feeds和Migrate。

Feed和Migrate之间的区别在于，Feed是为定期导入内容而构建的，而Migrate是为一次性将内容从一个地方移植到另一个地方而构建的。Migrate确实支持更新现有数据，但是，由于两个模块都得到了很好的支持，因此使用为手头任务而构建的模块更有意义-Feeds是更好的选择。

我自己使用了两个模块（用于同步的Feed，用于迁移的Migrate），我发现Feed不会比Migrate更混乱。根据我的经验，Migrate需要更多的自定义代码，尽管迁移整个网站比导入单个内容类型要复杂得多，所以很难进行比较。

4.用于远程存储，同步+缓存的自定义模块

有很多模块可以帮助完成此任务。

您提到了Web服务数据模块，而其他人提到了数据模块。要考虑的另一个选项是远程实体API模块。请注意，我经验丰富的人中只有一个是数据模块。

• Web服务数据模块尚未发布-可能表明代码尚未稳定，API可能会更改等等。它不支持实体字段查询（根据其项目页面），并且快速浏览代码存储库没有证据表明它具有Views支持-因此，您将无法使用Views来显示您的实体；

• 根据我的经验，“数据”模块面向的是非开发人员，他们将数据存储在表中并希望将其公开给视图。我发现Drupal 6版本使用起来非常令人沮丧-尽管此后可能会有所改变；

• 远程实体API模块听起来很有希望-它支持远程实体的获取和缓存，并具有Views支持。它仅在alpha版本上发布-因此API可能仍会更改。乍一看，它似乎也不支持实体字段查询，它仅支持一种类型的远程服务，因此您必须实现自己的。

结论

鉴于所有远程存储模块都不支持实体字段查询，因此使用实际的实体+提要是可以使您与Drupal站点实现最佳集成的解决方案。

如果Views支持足够，并且您不必担心通过“实体字段查询”与其他模块的潜在集成，那么使用“远程实体API”可能是可行的方法-但是您将需要实现自己的远程接口。

我认为，如果您需要视图，规则，令牌，crud钩子，搜索api和绝对强大的系统集成，则不能将其视为节点，但它们必须是自定义实体，并具有自己的特性，并在数据库中存储“实体id”和“外部ID”关系以及包含在“实体属性”中的检索信息调用。最后，无论您选择哪种用于同步数据的工具，我都将使用cron Queues对其进行处理。

如果您只需要准时检索和公开数据，我认为一个更好的选择是创建一个用于检索外部数据的Interface类，并使用从您的“农民市场”结构中检索信息的Class来实现此Interface。

问候

有Field Storage API，它允许默认数据库引擎以外的可插入存储后端。