实体在Drupal 7

Drupal 7中的Drupal实体是什么？我了解Drupal Commerce将产品构建为实体。我知道现在有一个核心的Entity API和对Entity API的贡献。

今年我有一些项目，我想使用Drupal 7，NoSQL，如果需要的话可以使用Entity API，但是我很难确定将在哪里使用。

假设您正在构建工作清单网站-某项工作不一定像节点内容，那么您是否可以将其设为实体？

另外，您是否仍然可以与Entity进行模块对话，这是如何完成的？就像，一个Job Posting实体使用Pathauto别名并在Views中公开，并显示在XML Sitemap中。

实体是由hook_entity_info（）定义的数据结构，并且可以设置字段，这意味着您可以向其添加字段。

在Drupal 7 Core中，节点，用户，注释，词汇和术语是实体。

在Contrib中，还有更多，例如私人消息和商业交易；例如；

但是，我认为职位发布非常适合作为节点：)实体不会自动具有Pathauto（令牌），Views等集成。

实体是节点，用户等上方的元级别。

本质上，如果您查看D6，则有很多重复的模块，并且这些类型的事物都具有功能。例如，有一些模块可以将cck字段附加到用户和分类术语。

在D7中，决定在结构上以相同的方式处理这些问题，因此，如果您有一个对实体起作用的模块，则该模块应适用于节点，术语和用户。

在以前的Drupal版本中，像Commerce这样的模块将有两个选择，一个是构建自定义节点类型，要么是完全脱离Drupal的内部系统并定义自己的事物类型。使用实体，可以将产品描述为一种事物类型，与现有类型不同，但是仍然可以利用其构成中的字段等功能。

假设您正在构建工作清单网站-某项工作不一定像节点内容，那么您是否可以将其设为实体？

你可以。我认为您应该小心不要太快地使事物实体化。通常，自定义节点类型仍然可以满足您的需求。作业是列出与节点不同类型的事物，还是节点具有某些特殊属性？

我已经开始在一些项目中使用实体来处理那些并非真正“内容”的东西。我们将它们用于我们真正不在乎它何时发布或作者是谁的事情。

定义实体的真正好处是，如果您正在开发自己的自定义模块。您可以免费获得漂亮的表结构和许多Drupal优点（Fieldability，Views集成...）。无需再创建自己的自定义表结构或根据需要改装节点类型。另外，我喜欢它们是多么轻巧，因此性能明智的实体应该更好。如果您在D6中使用节点进行了任何查询，您都会明白我的意思。

节点，用户，分类法是Drupal实体的示例。实体的主要特征是可以将其分配给其他实体：用户与节点关联，并且分类法可以分配给节点和用户。

如果您所描述的工作可以分配给用户或节点，那么我将其作为一个实体。如果您可以“工作”只是一种内容类型，那么我就不会使其成为一个实体。

如果您只想说几句话，那么您可以说en实体只是drupal知道的一条数据，并且可以存储在任何地方。