原文链接：http://www.istos.it/blog/drupal-entities/drupal-entities-part-2-what-where-and-when-entities

在第二部分我们将来探秘Drupal entities。在第一部分中我们介绍了entities的发展过程。在这篇文章中，我们将更深入的了解entities，并且讨论应该在什么情况下使用它。

在前一篇文章中我已经阐述了Drupal如何从以nodes作为其主要抽象单元过渡到entities的，但是我们只是通过Drupal历史来说明为什么使用entities而没有真正的说明白entities到底是什么。

这里我们将要来详细的说一说什么是entities，何时何地来使用它。我将不讲的过于技术（也就是：没有代码） - 我主要的目标是让大家明白entities到底是什么且能做些什么。在这个系列的最后一篇将比较技术（也就是：很多代码）。

What are Drupal Entities

在计算机科学领域中entities有许多意义，最常提到的意思，也是第一次提到Drupal entities时会在脑海中想到的，来自数据库的世界。对于数据库来说"entities"是我们希望在应用域中描述的"东西"。通常，这被用在解释Entity-relationship的流程图中 - 这也是许多计算机系一年纪学生肄业的原因。

Drupal entities在某种程度上是与之类似的。Entities是数据，是信息，是我们在Drupal应用中要处理的“东西”，然而相似之处也就仅仅那么多。当你思考Drupal entities的时候你只应该思考它在Drupal中运行方式。就像nodes一样，Drupal entities是一个新的概念，只是一个Drupal的属于并且只能在Drupal的上下文中定义。

所以我们在Drupal应用中到底想呈现什么样的“东西”？我们有nodes，taxonomy，users，comments，它们是Drupal的主要组成元素，并且在Drupal7中它们都是entities。

现在这样很好，但是这些都跟Drupal6一样对吗？所以，到底有什么不同？难道就是我们现在叫这些东西entities？

恩，不完全是这样。Entities现在在Drupal 7中有一套统一的处理方式，而在Drupal 6中它们各自有不同的方式（或者说是用不同的方法来重复相同的东西）。Entities通过一个共同的编程接口来定义绝大多数的行为。

所以，Drupal entities首先做的就是合理化，流程化我们处理Drupal基本元素nodes，comments，terms和users的方式。

现在来为并不是对Drupal核心运行方式十分感兴趣的人介绍真正有趣的部分。

1. 你可以定义自己的entities，并遵循Drupal运行的方式。

2. 任何entity可以添加fields。

记得CCK吗？记得它是对Drupal 6多么的重要吗？记得你是怎么通过添加fields来将nodes变成你想要的任何东西的吗？在Drupal 7中，所有的entities都有这样的功能，那意味着nodes，users，terms和comments都有这些功能。同样的，你自己定义的entities同样拥有这样的特性。这使得Drupal成为一个全新的游戏。

你现在可以为你的应用创建特定的数据结构，并且拥有它们自己的数据表（或者任何其他的存储机制），并且有标准的方式来为其添加fields。而不需要通过转换nodes来实现。

一些例子：

• Drupal 7 commerce模块使用entities在发票中描述了line item。Chx在IRC中跟我说他们发现这是一种很方便的方法去组织一个line item 的所有fields，而不用去思考如何用nodes来实现，同时也不需要引入复杂的方式来处理数据。
• Examiner.com团队使用entities来存储用户档案的修订信息（具体功能希望能在近期发布）。
• Drupal 7 Rules模块使用entities来存储Rules配置。

所以Drupal entities是：

• 向你的其余的Drupal 应用描述一种在你作用域中相关且特有的数据结构，它有自己的数据库表格，但同时......
• ...可以使用Drupal API来为其添加fields并且可以与之用多种方式来交互，这意味着......
• ...你可以简单的与Views模块集成，或者使用Mongo DB来存储数据。

但是，你如何决策在何时来创建一个新的entity，你是否需要给其添加fields或者在一张数据库表上存储其所有的数据，或者使用老方法通过nodes来实现？

何时，为何你应该使用entities

Entities仍然是一个很新的概念所有最佳的用例仍需要探寻。尽管如此，Chx和DamZ在IRC上给出了一些好的建议。

本质上来说，如果你需要将数据存入一张自定义的数据库表时，你需要考虑通过Drupal API来定义一个entity并为其添加fields是否值得。我给你一些提示 - 答案是：这是值得的，使用entities应该说是更好的选择。通过entities来组织自定义表单的数据几乎没有缺点。

在Drupal 6中你使用nodes来实现是非常有效的方法，但是节点本来是被设计用来做一些很特定的事情的 - 存储文章等。Drupal 7中，尽管如此，你可以创建一个简单的entity并且只附加你需要的fields。你不需要载入一些本属于node的但是你不需要的功能（例如：作者，发布日期等）。

Chx和DamZ认为数据库中的描述你entity的base table一般应该越简单越好，你可以通过附加fields来定义你的数据结构。

但是在如下情况你可能考虑不通过Drupal field API而是直接将entity属性定义在base table中：

1. 你的数据太过特殊，且不能被现有的field类型很好的支持。

2. 性能方面的考虑，查询一张表要比查询多张表要快（例如你打算经常的访问它）。

但是请记住，我们使用entities和fields最主要的原因是可扩展性 - 所以除非你确实需要为性能考虑，你可能还是会想使用fields这样的话你可以真正的决定它们如何被存储（例如：使用MongoDB而不是Mysql）。

那什么时候不适用entities呢？现在还没有用户界面来定义和处理entities。所以如果你想很快的且不用写代码的方法来完成一些事情，重新使用nodes依然是一个最好的方法。但是，如果你愿意稍微写一些代码（在下一篇文章中你会看到这真的不复杂），你可以有一个更加优雅的web应用，并且完全是Drupal的方式来完成的。

并不都是玫瑰花

就像我之前说的一样，entities仍然是一个很新的概念。并且把他们彻底的加入Drupal 7 是一个巨大的工程。所以这里还有一些没有完善的地方。

这里还没有一个统一的界面来定义和载入entities，这里（在Drupal核心中）还不能完成entities所有的操作（创建，读取，更新，删除），但是工作已经正在第三方模块中进行。

另一个问题是如何在这些entities中定义一些关系。Nodes，comments，taxonomy terms和users都与之有关。但这些被硬代码的（hard coded）关系非常苦难。再一次，这个工作也正在第三方模块中开发。

..但是它真的让人感到兴奋！

虽然现在这些都不完美，但是他们正在一个很好的发展道路上。正如Chx在IRC上对我说的一样，这将要花费我们几年的时间来探寻我们用Drupal 7能做的所有的事情。

这听起来肯定是对的 - 正如希望的那样，Drupal 8也将会发布，它将会更加棒！

感谢Chx花费时间在IRC上为我解释了许多东西并且审核了这篇文章，感谢DamZ的加入，并发表了一些非常有用的评论。