現在のD8ステータスでは、新しいコンテンツエンティティタイプを作成する場合と、「ノード」コンテンツエンティティのコンテンツタイプを作成する場合の決定ツリーは何ですか？

「新しいコンテンツタイプを追加するのではなく、エンティティを作成するのが適切な場合」という質問に対して受け入れられた回答が書かれてから4年、Drupal 8の最初のリリースがありました。また、エンティティは、Drupal 7よりもDrupal 8の中心です（RefB、RefC、RefD）。

この新しいDrupal 8の世界では、新しいコンテンツエンティティタイプと「ノード」タイプのコンテンツエンティティの新しいコンテンツタイプを作成するためのディシジョンツリーは何ですか？

応答を検討する際には、以下を考慮してください。

• 「ノード」のコンテンツエンティティタイプの新しいコンテンツタイプは、新しいコンテンツエンティティタイプに対して99％の状況でまだ適切ですか？
• デシジョンツリーには、「ノード」コンテンツエンティティタイプの使用を避け、代わりに新しいコンテンツエンティティタイプを作成する、より多くの、より良い、またはより明確な理由が含まれていますか？はいの場合、それらは何ですか？含まれますか：
  • パフォーマンス？
  • セキュリティ/許可？
  • Node-entity-type Content-Typesで動作し、他のコンテンツエンティティタイプでは動作しないモジュールの数は？
• おそらく-上記で参照された以前に受け入れられた回答に基づいて-カスタムコンテンツエンティティタイプを実行する唯一の一般的な理由は、ノードデータを分類用語などでグループ化するか、そうでなければコメントなどでノードに注釈を付ける場合ですか？

モジュールの互換性は、決定木にとって特に興味深い考慮事項のようです。現在、最もインストールされているモジュールのほとんどは、アルファ、ベータ、またはrc（リリース候補）だけではない8.xのリリースがあります。また、新しいカスタムエンティティタイプと新しいノードエンティティコンテンツタイプでは、それらのうち何個がそのまま使用できるかを特定することは難しいようです。「エンティティ用に作成されたもの」と「ノードエンティティコンテンツタイプ用に作成されたもの」を区別するプロジェクト属性はないようです。

pathautoを見てください。これは、現在、8.xリリースの種類があるモジュールの中で4番目にインストールされているモジュールです。人々は、ノードエンティティタイプのコンテンツタイプだけでなく、一般的にエンティティをサポートする8.xバージョンで一生懸命取り組んでいます。しかし、他のすべてのモジュールはどうですか？また、エンティティをサポートするモジュールは、通常、モジュールが動作する前に、モジュール固有の「フック」を持つカスタムコンテンツエンティティタイプを必要としますか？（モジュールが新しいコンテンツタイプですぐに動作する方法とは異なりますか？） それはpathautoチームが取り組んでいる種類の課題のように見えますが、おそらくカスタムコンテンツエンティティタイプから遠ざかる理由でしょうか？

Drupal 8コアには、タイプ「ノード」のコンテンツエンティティの新しいコンテンツタイプを作成するためのUIが含まれていますが、現在、新しいコンテンツエンティティタイプを作成するためのUIは含まれていません。（RefX、RefY、RefZ）

新しいノードエンティティタイプのコンテンツタイプを作成するか、新しいコンテンツエンティティタイプを作成するかを選択するための決定ツリー：

1. あなたはプログラマーですか、それともプログラマーに簡単にアクセスできますか？
   • いいえの場合、現在、新しいノードエンティティコンテンツタイプの作成にかなり制限されています。（新しいコンテンツエンティティタイプを作成するためのUIはコアにありません。また、Entity Construction Kit（ECK） contribモジュールには現在アルファリリースのみがあります。）
   • はいの場合、続行します...
2. データに活用したいcontribモジュールを正確に知っていますか？
   • 「いいえ」の場合、おそらく安全な方法はノードエンティティコンテンツタイプを作成することです。
   • はいの場合、それらのモジュールは、検討中のカスタムエンティティタイプを既にサポートしていますか、それとも、モジュール内で必要な機能を作成または再作成するためにそれらを強化するのに役立ちますか？
     • いいえの場合は、ノードエンティティタイプのコンテンツタイプを作成するだけが最適です。
     • はいの場合、続行します...
3. モジュールで有効になっている実際のコンテンツデータは、他のコンテンツデータのグループ化や注釈付けに役立つだけですか？（そのため、単独で表示されることはほとんどありません。）
   • 「はい」の場合、モジュールが分類法の用語およびコメントの既存のエンティティタイプに似ているかどうかを検討します。もしそうなら、新しいエンティティタイプが安全な賭けかもしれません。
   • いいえの場合、続行します...
4. 新しいノードエンティティタイプのコンテンツタイプがなぜ機能しないのかを明確に説明できますか？
   • いいえの場合、安全な方法は、おそらく新しいノードエンティティタイプのコンテンツタイプを作成することです。
   • はいの場合、続行します...
5. 最後に、Node-entity-typeを単に拡張することはできず、CRUD操作などの便利な機能をすべて再作成したいのですか？
   • はいの場合は、先に進み、新しいカスタムエンティティタイプを作成します。
   • 「いいえ」の場合、または不明な場合は、おそらく専門家に相談して決定を支援したいと思うでしょう。

ノート：

1. この決定ツリーでは、パフォーマンスやセキュリティは考慮されません。新しいカスタムコンテンツエンティティタイプがNode-entity-typeよりもパフォーマンスが良く、安全性が高いかどうか、またはいつになるかわかりません。
2. このツリーが適切な答えであったとしても、Drupalコアおよびcontribモジュールのリリースの更新のため、時間の経過とともにツリーが残ることはおそらくないでしょう。StackExchangeは、今日の「最良の」答えが明日の最良の答えではない可能性があることに対応していないようです。

この問題に関する簡単なアプローチは、プロジェクトの目的、規模、ビジネス要件を考慮することです。

1. デフォルトのノードエンティティコンテンツタイプが、プロジェクトドキュメントの分析的思考から生成されるアーキテクチャとデータフローに近い、簡単できれいな方法でプロジェクトを構築することにどのように影響するか。

ここでの重要な注意点は、新しいエンティティタイプを作成する決定は、通常、アプリケーションを管理し、ビジネスのみに専念するサイトビルダーまたはプロジェクトオーナーではなく、開発者または技術リーダーが行います。

2. Drupal 8はいくつかのsymfony2パッケージに依存しており、フレームワークにより近く、伝統的なcmsはその大きなアーキテクチャの変更を伴うDrupalについて語っていますが、新しいエンティティの構築は、ノードエンティティコンテンツタイプに対して多くのカスタマイズや複雑な構成を行うよりも優れていると思います多くの人がDrupalの設定や分散設定を好まないため、他のフレームワークの中でDrupalを活用するために、WordPressから来て、Drupalの管理ダッシュボードを扱うときにイライラさせる1つのフォームからすべてのものを設定するために使用される人々に直面するかもしれません

3. Drupalの9つの完全フックシステムを削除して置き換えることを計画イベントディスパッチャコードから既存の機能を変更するように、新しいエンティティを作成するには、管理インタフェースのための大きな必要性へのリードは非常に難しく、開発者ではなく、非常に不可欠になります人になることその機能を追加します。

最後に、プロジェクトのニーズに合わせて調整された新しいエンティティは、多数のフィールドを持つ複雑なコンテンツタイプよりも高いパフォーマンスを提供することがわかります。各フィールドはDBに2つのテーブルを追加し、特に重いビジネスロジックが必要です。

単純明快：すべてのコンテンツではありません。 コンテンツのリストは非常に長くなる可能性があり、コンテンツタイプのみを使用している場合は混乱を招く可能性があります。（ContentEntityBaseは、カスタムエンティティthoeによって実装することもできます）

作成者と公開状態がある場合は、コンテンツタイプを選択する必要があります。

それ以外の場合（プログラマーを想定）、カスタムエンティティを優先する必要があります。すべてのインターフェイス（リビジョン可能、フィールド可能、アクセス制限など）で簡単に実装できます。

私の見解では、これはより明確で、順序付けられたアーキテクチャーです（また、パフォーマンスも向上しています）。

いくつかのプロジェクトでの再利用性を考えると、カスタムエンティティを吹き飛ばす努力が必要です。drupal-code-generatorのような気の利いたヘルパーもいます。カスタムコーディング（または複雑さ）を低レベルに保つには、必要に応じてコンテンツタイプの使用を検討する必要があります。

• （少なくともD7では）「エンティティ」を翻訳するには、インターフェースもあります。
• （提案のために開いてください）..

正直なところ、それを実装して初めて理解できると思うのは難しい質問です。しかし、レミーが言及したように、すべてが生のユーザー向けコンテンツではない。

Drupal 7には、カスタムエンティティを作成する機能が存在していましたが、OOPで辺りが荒い場合は困難な作業になる可能性があります。それは半分実装された（または、あなたが言いたいのは半分行われた）ものであり、完全に均一ではなく、アプローチと合意されたOOPが混在するエンティティを作成する方法につながります。

Drupal 8では、このアイデアははるかに実現されており、カスタムエンティティで立ち上げて実行するのがはるかに簡単です。ノード自体はContentEntityBaseに基づいており、ブロック、ユーザー、ファイル、および分類も同様です。

ノードは、コンテンツとして（つまり、メニュー、サイトマップ、XMLサイトマップ、またはRSSフィードなどで）通常機能する公開された、可視（または承認済み）のコンテンツデータ専用です。Drupalは、ノード操作のプロセスの任意のステップにフックし、それを変更して、提供されたモジュールの誤った組み合わせがある場合に意図しない結果をもたらす可能性がある方法で設計されました。これはおそらく議論の余地のある意見ですが、エンティティの概念をさらに取り入れるためには、「すべてがノードである」という考えから自分自身を離すのに役立ちます。

優れたコンテンツタイプを作成する理想的なコンテンツ：

• 記事
• ページ
• 求人
• イベント
• ランディングページ
• ホームページ

彼らに共通するスレッドは、コンテンツのタイプの概念を共有していることです。通常、任意の数のワークフロー状態（公開、昇格、スティッキー、アーカイブ、機能など-カスタム公開オプションを使用する場合）であり、多数の提供モジュールがPathautoのように直接対話します。

しかし、内部、プライベート、他のデータ、または許可しない限りその範囲外での統合を許可しないデータを駆動するデータをDrupalに保存するとします。これはどのようなデータですか？以下にいくつかの可能なタイプを示します。

• 製品（Drupal Commerce）
• 広告申込情報（Drupal Commerce）
• 検索サーバー（ApacheSolr / SearchAPI）
• 連絡先（CRMリードなど）
• チケット（サポートチケットなど）

これらの違いは何ですか？ユーザーモデルを使用するのではなく、連絡先のエンティティが必要なのはなぜですか？そこでいくつかの引数をとることができますが、私の例では、連絡先フォームから電子メールアドレスと名前、その他のメタデータを収集する場合、そのデータをカスタムエンティティとして保存します。ユーザーリストが非アカウントアイテムで汚染されるのを防ぎ、潜在的なセキュリティ問題（スクリプトまたは誰かが誤ってそれらのアカウントを管理者に更新したり、大量メールを送信した場合）を減らし、実際のユーザーの内部オーバーヘッド管理を行いますアカウントを簡単に作成し、キャプチャしているものを、それが何であるか、つまり特殊なデータの一部に分割します。

ここからは、Drupal / Nodeシステムのより自動化された部分とは大きく異なり、アクションとエクスペリエンスを調整できます。ルート、アクセス、CRUDワークフローを決定します。

その考え方では、そのアプローチがそのように行われる理由を簡単に確認できます。サポートチケットの例を考えてみましょう-着信リクエストですが、データは公開されておらず、付着させたくないノードシステムの部分から離すよりも、設定が簡単な非常に具体的なワークフローを持っている可能性がありますに。

別の例は、外部のインポートされたデータです。ほとんどの場合、このデータは通常、ローカルのDrupalデータで強化されていません（たとえエンティティとしてであっても、それを行うことができます）。それは何でもかまいません。たぶんそれは請求書であり、多分それらは本であり、多分それはビールのブランドを引っ張っている。

このようなデータは通常特定のものであり、どのノードを対象とするかを超えた制御が必要です。それは、ノード上の参照フィールドを使用してカスタムエンティティ（これは、Drupal Commerceが何らかのレベルで機能した方法です）をポイントしてデータを強化することで、それを拡張できないということではありません。同時に、設計を超えてモデルに干渉する誤ったcontribコードから、データとUIの制御を分離して保証します。いくつかのフックは残っていますが、これはおそらくD8での問題ではなくD7での問題です。

現在、分離を促進するための適切なアーキテクチャが存在します。すべてがノードではありません。