延續上一篇文章<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 之間的差異。這個重大的改變來自三個方面：
- CCK被納入核心模組，改成 Field 模組。日後所有可以加入 node 的屬性都以欄位的方式呈現，而同一個欄位可以在不同的 entity 中被重複使用。
- Entity 之間能夠完全以 reference 欄位的方式來彼此關聯、引用。這保持了不同 entity 的關聯性，也讓關聯欄位有了調整彈性。
- 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 欄位，將會是必要的學習過程。
原文地址：http://www.drupaltky.org/article/43