浅谈 Entity 的概念

延续上一篇文章<Drupal Commerce 概念架构>， 本来打算要继续讲 Commerce 与 Views 整合的主题。不过由于这个主题牵涉到 Views 中的 Relationship 项目，而要讲清楚 Relationship 的用法又会涉及 Entity 的观念，想来想去，觉得还是先把这些观念弄清楚再继续讲下去会比较好。

先简单讲一下 "entity" 这个字 的中文翻译。"entity" 常见的翻译是“实体”，但严格来说（好啦，根据我的哲学癖来说），这不是一个好的翻法。哲学上来说，“实体”通常是用来翻译 "substance" 这个字，而 "substance" 到底是指啥可是个历史上出名复杂难解的议题（可以去 SEP 史丹佛哲学百科查一下）。撇开烦杂的理论问题不谈，在搜罗语词惯用法的维基字典上，"entity" 意义也不同于 "substance"。（这里是指英文版。中文版的翻译基本上完全忽视两者意义和用法上差异，把两者都翻成“实体”。然而基本上就算是看英文版，你也需要一些哲学训练才能搞清楚差别在哪里。

为什么 "substance" 常被翻成“实体”？因为它有表达物质、事物的本质等意思，通常是指那些占有时空位置的基本存有物以及/或者在环境变化中能够保持独立自存的东西（相对于事件或可被拥有/丧失的性质）。而 "entity" 则较为抽象，它表达任何独立自存的东西，而这些东西不一定会有物质性的存在。像是抽象存有物（数字）或虚拟存有物（孙悟空），或是无形体、非物理的东西（像是语言、鬼魂或精神...等等；如果你发觉你没法接受这些东西有“存在”可言，恭喜你，你刚发现自己是个物理论者了）。甚至在比较宽松的用法中，它可以指存有或存在的状态本身。

在这些的意义下，"entity" 比 "substance" 来得广泛与抽象。在其他较具体的脉络下， "entity"则被用来指涉抽象或具体的组织单位。在商业脉络中，"entity" 指能够进行商业活动的独特单位，像是一家公司、一个部门、一个团队组织，甚至是一个人。在计算科学中，则是指任何可以被存入资料库的资讯或资料。如果可以 理解 "entity" 和 "substance" 的这层对比，就可以为什么 "entity" 不该被翻成“实体”（因为那只是它的一部份而已嘛），而被翻译成“存有物”、“元目”甚至俗称的“东西”都还好一点。由于我们在这里讨论的是计算科学中的 应用，把 "entity" 翻成“单元”，比较可以保持它既能表达具体事物又能表达抽象存有的意涵。

接下来回去讲 Drupal。

Node 的时代

在 Drupal 4.x ~ 6.x 的发展过程中，内容管理的主要角色是 node（中文多翻成“节点”）。在这个阶段，CCK 模组是必备的第3方模组，用来规划与自订各种 node type，也就是“内容类型”。而内容类型之间的差异就在于其组成元件—field（栏位）—的不同搭配方式。而 node 之外的其他项目，比方说分类词(taxonomy term)或者位置(Location)，则被设计成可以被组装到 node 上的配件。

以分类词来说，使用过 Drupal 4.x ~ 6.x 的人都应该很熟悉 taxonomy 模组，通常的设定方式就是在主分类(vocabuary)设定页中，将某个主分类指派给一个或多个内容类型。设定好之后，在新增这些类型的 node 的表单中就会出现属于该主分类的分类词选单或输入框，让使用者替该 node 指派或建立分类属性。

然而，在这个阶段大家会共同有的一个困扰就是，这些被额外装配进来的属性项目不像 CCK 栏位那样好控制或者客制化。在 CCK 的“栏位管理”里头，你可以自由拖放栏位次序，调整不同栏位在 node 的检视模式(view mode)中的显示方式。Taxonomy 等模组虽然可以大大扩充 node 的属性与功能，但是没法子像 CCK 栏位那样有弹性，可以方便地进行调整。后来开发出的 taxonomy image 或者 content taxonomy 等模组就是在这样的架构下试图去克服这个缺点，后来也的确愈来愈流行，变成几乎像 CCK 那样的必备模组。

Enity 的概念

可以说 Enitty 的概念就是为瞭解决这个问题而提出来的。毕竟，如果 CCK 这么好用，那为什么不把所有的东西都纳入这个架构呢？Drupal 7.x 放弃了 node 为设计中心的架构，而改采一种去中心式的、但可以彼此关联的分散架构。在这个新架构底下，没有 node 和属性的区别，只有 entity 之间的差异。这个重大的改变来自三个方面：

1. CCK被纳入核心模组，改成 Field 模组。日后所有可以加入 node 的属性都以栏位的方式呈现，而同一个栏位可以在不同的 entity 中被重复使用。
2. Entity 之间能够完全以 reference 栏位的方式来彼此关联、引用。这保持了不同 entity 的关联性，也让关联栏位有了调整弹性。
3. Entity 表单栏位与栏位显示(display)的分离。这点完全解放了 node 前后台的对应架构，让 node 的表单和检视模式可以独立开来，不仅可以让表单元素可以在检视模式中有不同的排版顺序，更可以隐藏有资料库用途但不必要显示的元素。而其他模组（如 views attach）也可以利用这点，将其他资料化为显示栏位，呈现在 node 里头，而不必新增一个表单栏位才能做到。

这样讲可能还是太过抽象，举一些例子可能会比较好懂。情况是，几乎所有过去被当作是附加属性的东西，像是 user、taxonomy、comment 等等，在 7.x 里面都变成了独立的、可装配栏位的 entity。所以我们可以在某个 vocabuary 里头加装图片栏位 field_image，替不同的分类词加上不同的代表图片。我们也可以在 comment 中重复使用同一个图片栏位 field_image，让发表回应的使用者可以自行上传与该回应有关的图片（比方说萤幕截图）。或者我们可以在 user 里头加装一个文字栏位，搜集使用者的姓名、联络电话或者邮寄地址。

Drupal 7.x 预设有两个 reference 栏位，user reference 与 term reference 。可以用来在 entity 中引入 user 和 taxonomy tern 这两种 entity。不过加装了 Entity Reference 这个模组之后，基本上你可以在任一种 entity 中引入任何其他种的 entity。比方说，一般的情况下，在“文章”entity 中可以引用 user 和 term 这两种 entity，用来连结相关的“作者”和“分类标签”。在进阶的用法里，你可以在 user 中引用 term，将使用者分门别类。或者在 comment 中引用“部落格文章”entity，让使用者在撰写评论时可以加入“相关部落格”资讯。假设你有 n 种 entity，就可以有 n × (n-1) 种引用连结的方式，全看你要满足什么样的需求。

Entity 与 Views

这种去中心但又可互相引用的设计，带来了内容架构上的超大弹性。这不仅影响到单一的 node 会如何编辑和呈现，也让 Views 的建置工作有了根本的变化。在过去的 Views 管理介面中，user、term 里头的相关资讯预设都被放在“栏位”里头，和所有 node 里头的栏位没有两样。但是在 Views 3.x 里头，“栏位”里头将没有固定的项目，而是会随着前述 reference （引用）关系变化。

举例来说，当我们在 Views 过滤出属于 A entity 的节点项目时，可加入的“栏位”项目将只限于与 A 有关的栏位。假设 A 透过 reference 栏位引用了 B entity，那么就可以利用这个引用关系，把属于 B 的相关资讯加到“栏位”中，共同呈现在 views display 里面。具体说来就是，你可以制作一张表格，列出你所有的“农产品”节点标题以及它们所引用的的“分类”标题。在过去，这种作法大概就是可处理的极限了。但 在 drupal 7 中，如果你的“分类”项目中有图片或文字栏位（比方说“英文标题”），你都可以透过在 Views 中加入这种引用关系，而把这些图片或文字等属于 B 的栏位资讯，加入到同一张表格里头。（换言之就是，你可以用“分类图片”取代“分类标题”来标示出产品的类别）

在 Views 中利用引用关系而加入所需栏位的具体作法，就是使用它的 Relationship 功能。Views 7.x 的一个重大变革就是，过去少用甚至完全不会用到的功能， relationship，变成了和 Context Filter（过去的 Argument）同等重要与基本的项目。如果你想要制作丰富与多元的 view display 来呈现复杂的资料关系，瞭解 entity 的概念以及怎么样在 Views 中透过 Relatinship 来结合不同的 entity 栏位，将会是必要的学习过程。

下一篇文章就要来谈一下 Views 7.x Relationship