使用定制Entity的时机和动机

##介绍

Drupal 7开始出现了Entity，这一改进大大的提高了Drupal模块的数据建模能力。在这之前，Drupal是一个为文章设计的数据结构，我们的方案和数据建模只能在这个基础上修修补补。

然而，在我们已经习惯于利用内容类型和字段解决所有的数据模型问题的情况下，向Entity迁移也的确不是一个轻而易举的事情。

##Entity需要一些时间和经验

如果你没有很多时间，也没有直接面对Entity API的经验，而手上的项目又逼近Deadline，那么这不是一个开始Entity的好时机，Entity的学习曲线也是颇为陡峭的。

利用 Entity construction kit(ECK)可能可以简化这一学习过程，这个模块提供了一个Entity的管理界面，尽管如此，要获得Entity的好处，还是需要一些开发工作的。ECK支持Features，能够把一个自定义Entity导出成为代码化配置，并且封装成为一个现成的模块形式。

尽管受限于实际情况，你可能不能立即投入Entity的怀抱之中，不过尽早投入时间来学习Entity还是值得的。

##Entity是什么

如果你想要建模的对象是某种类型，具体的内容可以通过一个唯一的URL来访问和查看，那么这几乎一定应该用Node而不是Entity来完成，例如一种新的文章类型。

另一个极端是，如果你面对的对象是纯粹的数据，他可能在展现之前首先要进行一些处理，或者仅作为页面的一部分而出现。一个例子就是Web版的接机大屏幕中显示的出港进港数据。

但是实际情况是，多数问题都不会是这种极端情况，可以借助在其他的框架下的经验来判断，是否使用定制Entity。

一些参考指标：

• 相对来说，存活期越短的东西越可能用定制Entity。（真心不懂，原文：Relatively short lived things are more likely to be custom entities than long-lived things (which may have a web presence)）

• 包含用于获取其他数据或者内容的元数据，比如一个用于获取存储在云服务上的视频的元数据，用定制Entity实现可能比较好。

• 不可见数据，例如从第三方API获取的一些数据，这些数据可能被其他的代码使用，但是通常是不会在同一个请求中立即使用，这种状况也是比较适合使用自定义Entity。

• 仅作为其他显示的一部分的内容也建议使用自定义Entity。

##性能和确定性

如果你拥有一个大型的复杂的站点，这一站点有很多不同事物需要被建模，如果全部使用Node实现，这导致一个后果：即使没有需要，Node相关的Hook也会影响所有这些内容。这也会导致对Node的管理工作臃肿复杂。

另外，Node的版本化特性也消耗了更多的性能。

甚至有些模型连Field都不需要，他们的属性仅使用Entity属性就能完成，无需数据库JOIN就能完成工作。（讽刺的是，起初，我们想要所有东西都能Field，现在，我们又发现，有时需要干掉Field）。

所以有时对Entity的合理使用能够让站点变得简洁，并提供更大的性能潜力。

##迎接即将到来的Drupal 8

貌似Drupal 8还要很长时间才能面世，然而该来的总会来，未雨绸缪是必要的。使用Drupal 7核心以及Entity API模块中的API，具有大量的例子和线上资源，也能让你有个较好的升级基础。

##其他Entity模块的助力

有大量的模块使用Entity API提供服务，使用Entity就让你可以通过Entity API使用其他模块的功能，例如可以利用Entity cache模块实现缓存。

##继续作恶？

可能你已经认识到，你现在的站点上的数据模型丑恶如斯，那么是时候从技术债中拯救你自己以及你的继任者了。一个Entity的反模式：分类词是核心成员之一，能够挂接Field，又具有管理页面，这种种优势导致他被过度使用，甚至在根本同分类无关的场景之中也牵强使用分类词。

这种情况在从Drupal 6中升级过来的Drupal 7站点中尤其常见。