今年の１月に正式にリリースされた Drupal 7 は、
様々な面で大きな変更が施されており、その結果 CMS として格段の進化を遂げているように感じる。
私は、Drupal 開発者として、当サイトを Drupal 7 へとアップグレードした経験 から、その中でも、特に、
という点が、Drupal 7 における最も大きな変更点ではないか、と考えている。
Drupal 6 においては、コンテンツを取り扱うものと言えば「node」であり、
Drupal で開発を行うためには、まず、この「node」について深く理解することが必須であった。
では、Drupal 7 において、Drupal で開発を行うためには、
まず、この「Entity」について深く理解することが必須であるのかと問われれば、どうであろうか。
答えは必ずしも「YES」というわけではないだろう。
つまり、
という程度の理解がありさえすれば、Drupal 7 においても、「Normal site（通常のサイト）」であれば、
これまで同様「node」を用いて「node」をベースにして様々なコンテンツタイプを作成・利用すればよいのである。
「node」は、これまでどおり、非常に優秀で柔軟性のあるコンテンツタイプである。
それでは、「Entity」は無用の長物なのかと問われれば、どうであろうか。
その答えは完全に「NO」である。
つまり、より大規模なサイト・より高度なサイト・より複雑なサイトを構築・運用しようとする場合には、
この「Entity」を利用することにより、さまざまなメリットを得ることができると考えられるのである。
Drupal は、ホワイトハウスの Web サイトを支える CMS として採用されたことからも伺えるように、
その機能性・信頼性に対しては最大級の評価を得ていると言えるが、私には、
Dries Buytaert 氏を始めとすると Drupal コアの開発者達が Drupal 7 に「Entity」という概念・実装を導入した背景には、
という意図があるように感じられる。
Drupal コアの開発者達は早くも Drupal 8 を見据えて動き出そうとしているようであるが、
Drupal は、今後、より「Advanced site」をそのターゲットとするように進化していくものと思われる。
このコラムでは、TransNetCreation が当サイトにおいてオリジナルの「Entity」を導入した経験を踏まえて、
前段において「Entity」について解説を試みた後（Section.2〜7）、
サイトオリジナルの「Entity」を導入することに関して、そのメリット・デメリットを考察することとする（Section.8〜16）。


　※当コラムは、「スライドショー」になっています。
　　Next ボタン のクリックにより、ページ遷移無しで、瞬間的に「次のセクション」に切り替わります。
　　同様に、Prev ボタン のクリックにより「１つ前のセクション」に、
　　First ボタン のクリックにより「最初のセクション」に、
　　Last ボタン のクリックにより「最後のセクション」に切り替わります。

繰り返しになるが、Drupal 6 においては、コンテンツを取り扱う概念・実装は「node」のみであった。
その特徴は、次のように整理することができるだろう。
特に上記の２の後段の、
「追加フィールドに、様々な機能を実現するためのプログラム処理を行わせることができる」
という特徴により、Drupal は非常にユニークな CMS となっている。

ここで、Drupal 6 におけるコンテンツに関する概念構造を整理すると、次ページの図のようになる。
まず、「コンテンツの概念・実装」として「node」があり、
その基本的な特徴を受け継いだ具体的な「コンテンツタイプ（node type）」として「story」「page」などがあり、
その「コンテンツタイプ（node type）」が実体化したものが「web ページ」となる。
もし読者の方がプログラマーであれば、上記の説明と次ページの図をご覧になり、これらの関係性が、
「オブジェクト指向プログラミング」における「クラス」と「インスタンス」の関係性に似ていることに気付かれるかもしれない。
「オブジェクト指向プログラミング」を喩えにすると、具体的には、
「スーパークラス」として「コンテンツの概念・実装」としての「node」があり、
それを継承した「サブクラス」として「コンテンツタイプ（node type）」としての「story」「page」などがあり、
そのサブクラスのインスタンスとして「web ページ」がある、ということになる。
また、ここでは説明を省いているが、CCK モジュールによる追加フィールドは、
「オブジェクト指向プログラミング」における「インターフェース」のように機能しているとも言える。

一方、Drupal 7 においては、コンテンツに関する概念構造を整理すると、次ページの図のようになる。
まず、「コンテンツの概念・実装」として「entity」があり、
その基本的な特徴を受け継いだ具体的な「エンティティタイプ」として「node」などがあり、
さらにその基本的な特徴を受け継いだ具体的な「バンドルタイプ」として「article」「page」などがあり、
その「バンドルタイプ」が実体化したものが「web ページ」となる。
これらの関係性も、先程の Drupal 6 の場合と同様、
「オブジェクト指向プログラミング」に喩えて理解することができる。

また、コンテンツの概念構造について Drupal 6 と Drupal 7 を比較すると、以下のようになる。

以上、コンテンツの概念構造について、Drupal 6 と Drupal 7 を比較することにより、
Drupal 7 における「Entity」がどのようなものであるかが明確になってきたものと思われる。
ということで、次セクション以降、
個別のサイトにおいてサイトオリジナルの「Entity」を利用するメリット・デメリットについて考えていきたい。

「Entity」は、登場して間もないということもあり、その利用方法については、
Drupal コミュニティにおいても、まだ手探りの状態にあるようである。
しかし、一般的には、次のような場合に「Entity」を利用することが適していると言われている。
（１）に関しては、Drupal 開発の当然の作法により、「Entity」はモジュールとして構築することになるため、
「Entity」用のモジュール（この場合はたいていカスタムモジュールとなる）において、
独自の権限処理・ワークフローを組み込む（プログラミングする）ということなる。
（２）に関しては、「Entity」用のモジュールにおいては、
Drupal が用意するデータベースではなく、独自のデータベースを使用することになるため、
レガシーなデータベースをそのまま使用することが可能になる場合もある（ただし条件がある）。
また、データベース関連で追加的に言及すると、
（１）で挙げた e-コマースにおける「商品（products）」のように、非常に頻繁なアクセスが生じるデータベースで、
なおかつ、「node」の処理に付随する他の様々なデータベースとの関連が不要な場合にも、
オリジナル「Entity」を利用することにより、データベースアクセスを単純化して（かつ、必要な処理のみを実装することにより）、
処理を軽くする（サーバの負荷を軽減する）ことが可能となる。
（３）に関しては、例えば、「article」のサブタイプ（下位タイプ）として
「article book」「article music」「article movie」が必要であるような場合、「node」では実現することができないが、
オリジナル「Entity」を利用することにより、それを実現することが可能となる。

さらに、一部のコアな開発者においては他にも色々な利用方法が模索されているようであるが、
ここでは、TransNetCreation が 当サイトにオリジナルの「Entity」を導入した 開発体験から得られた知見に基づいて、
という４つの観点から、次セクション以降、
特に、大規模サイトにおいてオリジナルの「Entity」を導入することのメリット・デメリットについて考察してみたい。

まず「開発面」であるが、ここではそれを「ＭＶＣ（Model View Controller）」に基づいて考えてみる。
「ＭＶＣ」とは、上記リンク先ページ（Wikipedia）の記述にあるように、
である。
これを Drupal に当てはめて考えると、「node」を利用した場合には、極限まで単純化すると、
ということになる。

ここで、例えば、「node」というエンティティタイプのサブタイプとして、
「my content type」というバンドルタイプを考えてみる。
「my content type」をサイトで利用するためには、
前ページの（１）の model・controller については Drupal に任せておけば良いが、
（２）の view についてはサイト開発者が独自に開発を行う必要がある。
具体的には、「my content type」を想定通りに出力・機能させるために、次のような開発作業が必要になる。
つまり、model・controller に関しては、開発者は特段の対応をする必要はないが、
view に関して、上記（Ａ）〜（Ｅ）のような作業が必要となる。
ここでの問題点は、サーバーサイドのプログラミングコードが、（Ａ）（Ｂ）（Ｃ）に分散して設置されることになる点である。
この点は、小規模サイト、少人数による開発、更新頻度が少ないなどの場合には問題になりにくいが、
大規模サイト、大人数による開発、更新頻度が多いなどの場合には、開発効率・開発速度に対してマイナスに影響することになる。
また、Drupal 6 から Drupal 7 のようなメジャーなバージョンアップに対応する場合（upgrade）にも、
テーマにおいては個別的な対応になりがちであるために、非常に多くの労力が必要になるという点でも問題になりやすい。
つまり、サイトの更新に関する困難度がアップし、結果としてサイトの柔軟性が失われ、サイトが硬直化し、
ユーザーから見た時のサイトの鮮度が落ちることに繋がりかねないという危険性を孕んでいる、ということである。

次に、「my content type」というバンドルタイプを、サイト独自の「Entity」を用いて構築する場合を考えてみる。
この時、「my content type」をサイトで利用するためには、
前々ページの（１）の model・controller についても、（２）の view についても、
サイト開発者が独自に開発を行う必要がある。
一方、前ページの（Ａ）〜（Ｅ）に関しては、
その全てを、独自に開発する「Entity」モジュール内に一括して設置することができる。*
つまり、サイトの開発段階においては、model・controller の開発の必要性というデメリットがあるが、
運用段階においてサイトを更新していく作業においては、「node」を使うことにより生じるデメリットを回避し、
高開発効率・高開発速度というメリットを獲得することができるわけである。
つまり、これらのメリット・デメリットをどのように勘案するかということになる。
しかし、現在、Web サイトの展開に関しては、
との認識が共有化されつつあり、この点においては、独自の「Entity」の導入はメリットをもたらすと言えるであろう。
つまり、サイトの更新が容易化・迅速化し、結果としてサイトのユーザー対応への柔軟性がアップし、
ユーザーから見た時のサイトの鮮度を高く保つことが可能になる、ということである。

　* 現実的には、（Ｄ）（Ｅ）については、テーマにおいて設置することになる場合が多いかもしれないが、
　  それでも、サーバーサイドのプログラミング部分については一括管理することができる。

次に「リクエスト処理面」について考える。
Drupal の「node」は、非常に豊富な機能を有しているが、
それは裏を返せば、そのために、様々なプログラミング処理やデータベースアクセスが発生している、ということである。
セクション 8 において言及したことの繰り返しになってしまうが、
e-コマースにおける「商品（products）」のように、非常に頻繁なアクセスが生じる場合で、
なおかつ、「node」の処理に付随する他の様々な付加的な機能が不要な場合には、
オリジナル「Entity」を利用することにより、データベースアクセスを単純化して、かつ、必要な処理のみを実装することにより、
リクエストに対する処理を軽くする（サーバの負荷を軽減する）ことが可能となる。
この点も、オリジナルの「Entity」を導入することの大きなメリットであると言える。

３番目に「データ保守面」について考える。
「node」を利用した時には、データは、node モジュールが用意・管理するデータベースに保存されることになる。
また、新規にフィールドを追加している場合には、そのフィールドのデータに関しては、
そのフィールド用モジュールが用意・管理するデータベースに保存されることになる。
このことは、
ということを意味している。
Drupal は素晴らしい CMS ・Web アプリケーションフレームワークであり、開発も非常に活発に進展しているようである。
その意味では、現時点及び近未来においては、Drupal を用いるという選択に関する不安材料は少ないと言える。
しかしながら、それが未来永劫続くかどうかは、誰も保証できるはずがないし、
Drupal の強力なライバルが登場するかもしれないことを、誰も否定することはできない。
つまり、重要なデータは、Drupal との関係性をできるだけ「疎」の状態にしておいて、
可能な限りその可搬性を確保しておいた方が良いということである。
この側面から、
という選択肢は大いに考慮すべきであると考えられる。
つまり、オリジナルの「Entity」を用いることにより、
のである。
このようにすることで、そのデータベース（＝テーブル）は、いつでも Drupal と切り離して利用可能となるのである。
また、この観点からは、
という開発方針が導かれることにも留意しておきたい。

４番目に、「コンテンツ作成面」について考える。
実際に「Entity」を開発・運用している経験に基づいて、実感として言えば、
良く考えて開発されたオリジナル「Entity」であれば、
ということである。
この点は、セクション 8 においても、
ということで言及したが、特に、
ため、大きなメリットとなると考えられる。

以上、４つの側面から、オリジナル「Entity」導入に関するメリット・デメリットを考察してきた。
結論としてまとめると、オリジナル「Entity」導入に関しては、次のように考えることができる。
サイトの開発段階においては、
というデメリットがある反面、サイトの運用段階においては、
というメリットを得ることができる。
以上を勘案した上で、
という判断になるであろう。

ただし、これは、オリジナル「Entity」導入に関する、一般的な利用方法に限定した判断フレームワークである。
繰り返しになるが、「Entity」に関してはその活用方法はまだまだ模索中である面があり、
今後より有用・有益な活用方法が発掘・提案される可能性もある。
先進的なサイト管理者の方は、その辺りへの目配りをしておくと良いかもしれない。


　※今回のコラムでは、「Entity」の導入が Drupal 7 の最も大きな変化であり進化である、と捉えていますが、
　　Drupal 7 は、セキュリティに関して、
　　その開発用 API そのものの中に SQL インジェクション 対策を組み込んでいる
　　という、もう一つの、大幅な改善点を有しています（一般的にはこちらのインパクトの方が大きいかもしれません）。
　　つまり、システムとして Drupal 7 を選択することが、即ち、SQL インジェクション対策となる、わけです。
　　この点については、Drupal 7 の公開直後におけるレビュー記事「祝! Drupal 7 正式リリース」に追記しています。
　　　（※2011年08月18日追記）