在当前D8状态下，创建新的内容实体类型与为“节点”内容实体创建内容类型的决策树是什么？

自从接受有关问题“ 何时创建实体而不是仅添加新的内容类型才合适？” 这一问题的答案以来，我们已经见证了Drupal 8的四年发布。而且，实体在Drupal 8中比在Drupal 7中更重要。（RefB，RefC，RefD）

在这个新的Drupal 8世界中，用于为“节点”类型的内容实体创建新的内容实体类型与新的内容类型的决策树是什么？

在考虑回应时，请考虑以下几点：

• 与新的内容实体类型相比，在99％的情况下，仍适用于“节点”的内容实体类型的新“内容类型”吗？
• 现在，决策树是否包括更多，更好或更清楚的理由，转而不再使用“节点”内容实体类型，而是创建新的内容实体类型？如果是的话，那是什么？它们是否包括：
  • 性能？
  • 安全/权限？
  • 可以与Node-entity-type Content-Types一起使用而与其他内容实体类型不一起使用的模块数量？
• 也许-基于上面引用的先前接受的答案-进行自定义内容实体类型的唯一一般原因是，如果您想对Node数据进行分组（例如，使用分类术语），还是要对Node进行注释（例如，使用注释）？

模块兼容性似乎是决策树特别有趣的考虑因素。当前，安装最多的模块很少有8.x发行版，而不仅仅是alpha，beta或rc（发行候选版）。似乎很难确定其中有多少将使用新的自定义实体类型与新的Node-entity内容类型开箱即用。似乎没有项目属性可以区分“为实体编写”和“为节点实体内容类型编写”的属性。

看一下pathauto，它是当前所有版本8.x的第四大安装模块。人们正在努力开发一个8.x版本，该版本通常支持实体，而不仅仅是节点实体类型的内容类型。但是其他所有模块呢？支持实体的模块通常需要自定义内容实体类型时，才具有与模块相关的“挂钩”吗？（相对于这些模块如何直接使用新的Content Types开箱即用？） 这似乎是 pathauto团队正在处理的挑战，也许这是偏离自定义内容实体类型的原因吗？

还可能值得一提的是，Drupal 8核心包含一个用于为类型“节点”的内容实体创建新的内容类型的UI，但当前不包含用于创建新的内容实体类型的UI。（RefX，RefY，RefZ）

在创建新的节点实体类型的内容类型与新的内容实体类型之间进行选择的决策树：

1. 您是程序员，还是可以轻松访问程序员？
   • 如果没有，那么您目前几乎仅限于创建新的节点实体内容类型。（核心中没有用于创建新的内容实体类型的UI，并且Entity Construction Kit（ECK）贡献模块当前仅具有alpha版本。）
   • 如果是，则继续...
2. 您是否确切知道要为数据使用哪些contrib模块？
   • 如果否，那么安全的选择可能就是创建一个节点实体内容类型。
   • 如果是，这些模块是否已经支持您正在考虑的自定义实体类型，或者您愿意帮助增强它们，以便它们将在您的模块中重新创建所需的功能？
     • 如果否，那么只创建一个Node-entity-type内容类型可能是最适合您的。
     • 如果是，则继续...
3. 您的模块启用的实际内容数据是否仅会帮助对其他内容数据进行分组或注释？（因此很少单独查看它。）
   • 如果是，则考虑您的模块是否类似于分类术语和注释的现有实体类型。如果是这样，那么新的实体类型可能是安全的选择。
   • 如果否，则继续...
4. 您能否清楚说明为什么新的Node-entity-type内容类型对您不起作用？
   • 如果否，那么您的安全选择可能就是创建一个新的Node-entity-type内容类型。
   • 如果是，则继续...
5. 最后，您确定不能仅扩展Node-entity-type，还想重新创建其所有有用的功能，例如CRUD操作吗？
   • 如果是，则继续创建新的自定义实体类型。
   • 如果没有，或者不确定，那么您可能想请一些专家帮助您做出决定。

笔记：

1. 该决策树不考虑性能或安全性。我不确定新的自定义内容实体类型是否或何时会比Node-entity-type更好，更安全。
2. 即使这棵树是一个很好的答案，由于Drupal核心和contrib模块的更新，它可能不会随着时间的流逝而成为一棵树。StackExchange似乎无法容纳今天的“最佳”答案可能不是明天的最佳答案。）

解决该问题的一种简单方法是考虑项目目的，规模和业务需求。

1. 默认节点实体内容类型如何以一种简单，整洁的方式影响项目的构建，使其更接近于项目文档的分析思想所产生的体系结构和数据流。

重要的是，创建新实体类型的决定通常由开发人员或技术主管而不是站点构建者或管理应用程序且仅专注于业务的项目所有者做出。

2. Drupal 8依赖于一些symfony2软件包，并且更接近框架，传统的cms谈论Drupal的开发具有巨大的体系结构更改，我设想建立一个新实体比按顺序对节点实体内容类型进行许多自定义和复杂配置要好要在其他框架中利用Drupal，因为许多人不喜欢Drupal的配置和分布式设置，您可能会遇到一些来自WordPress的人，并且曾经使用一种形式来配置所有内容，这使他们在使用Drupal管理仪表板时感到恼火。

3. Drupal 9计划完全删除钩子系统，并替换为事件调度程序，这导致非常需要管理界面来创建新实体，因为对于非开发人员来说，更改代码中的现有功能将变得更加困难，并且对于添加该功能。

最后，我看到针对项目需求量身定制的新实体比具有大量字段的复杂内容类型具有更高的性能，因为我们现在每个字段向数据库添加2个表，并且需要在每个请求上加载其配置，尤其是在需要繁重的业务逻辑。

简单明了：并非全部。 如果您仅使用内容类型，则内容列表可能会很长且令人困惑。（ContentEntityBase也可以通过自定义实体thoe来实现）

如果您有作者和出版状态，则应选择一种内容类型。

否则（假设您是程序员）应首选自定义实体。所有接口都可以轻松实现很多功能（例如可修改的版本，可现场使用的字段，访问限制等）

在我看来，这只是更清晰，尾部排序的架构（而且性能更高）。

考虑到几个项目中的可重用性，努力使自定义实体崩溃。.还有像drupal-code-generator这样的漂亮助手。为了将自定义编码（或复杂性）保持在较低水平，如果需要，您应该考虑使用内容类型：

• 为了翻译“实体”（至少在D7中），还将有一个接口。
• （建议公开）..

老实说，这是一个棘手的问题，我认为只有在您以前实施它之后，才能理解它。但正如雷米所言，并不是所有的东西都是原始的，面向用户的内容。

在Drupal 7中，存在创建自定义实体的功能，但是如果您对OOP不太了解，这可能是一项艰巨的任务。它是一半实现的（或者一半完成了，不过您要说的是完成），这导致了使用混合的过程和混合的OOP创建并非完全统一且商定方法的实体的方法。

在Drupal 8中，这个想法更加实现了，并且使用自定义实体启动和运行起来要容易得多。节点本身，块，用户，文件和分类法都基于ContentEntityBase。

节点专门用于发布的，可见的（或授权的）内容数据，这些数据通常充当内容（即在菜单，站点地图，xml站点地图或RSS feed等中）。Drupal的设计方式是，您可以挂接到节点操作过程的任何步骤并对其进行更改，如果您对贡献模块的混合不正确，可能会产生意想不到的后果。这可能是一个有争议的观点，但是它有助于使自己脱离“一切都是节点”的思想，以便更多地接受实体概念。

理想的内容，可组成出色的内容类型：

• 文章
• 页
• 招聘启事
• 事件
• 登陆页面
• 主页

它们的共同点是它们共享一种内容类型的概念。它通常处于任何数量的工作流状态（如果使用自定义发布选项，则处于已发布，已升级，已黏滞，已存档，已选中等），并且大量的已贡献模块直接与之交互，例如Pathauto。

但是，假设您要在内部，私有，驱动其他数据的数据存储在Drupal中，或者除非您允许，否则不应在其范围之外进行集成的数据。这可能是什么样的数据？以下是一些可能的类型：

• 产品（Drupal Commerce）
• 订单项（Drupal Commerce）
• 搜索服务器（ApacheSolr / SearchAPI）
• 联系人（如CRM主管）
• 票（如支持票）

是什么使它们如此不同？您为什么要实体联系而不使用用户模型？您可以在此处输入一些参数，但我的示例将是：如果您说要从联系人表单中收集电子邮件地址和姓名以及其他一些元数据，请将该数据存储为自定义实体。您可以防止用户列表受到非帐户项目的污染，减少潜在的安全问题（如果脚本或某人意外地将这些帐户更新为管理员或发送大量邮件该怎么办？），您可以对实际用户进行内部间接费用管理更轻松地进行帐户核算，然后将要捕获的内容细分为真正的数据（专用数据）。

从这里开始，它在很大程度上与Drupal / Node系统的自动化部分脱离了，您可以定制操作和体验。您确定路线，访问和CRUD工作流程。

在这种思维方式下，可以更轻松地了解为什么采用这种方法。以支持通知单为例-它是传入请求，但不是已发布的数据，并且可能具有非常特定的工作流程，与将其与不希望其遵循的节点系统部分分离相比，它的设置方式更容易至。

另一个示例是外部的导入数据。在大多数情况下，此数据通常不包含本地Drupal数据（即使作为一个实体，您仍然可以做到）。可能是任何东西。也许是发票，也许是书，也许正在拉啤酒品牌。

像这样的数据通常是特定的，并且需要超出节点含义的控制。这并不是说您不能通过使用节点上的引用字段来指向您的自定义实体（这在某种程度上就是Drupal Commerce的工作方式）来丰富数据来扩充它。同时，您正在隔离并确保对数据和UI的控制与超出其设计范围并干扰模型的错误贡献代码无关。尽管仍然存在一些问题，但与D7相比，D8中的问题可能更少。

现在存在适当的架构来鼓励分离。并非所有事物都是一个节点。