Когда уместно создавать сущность, а не просто добавлять новый тип контента?
В чем преимущество создания новых типов сущностей по сравнению с простым созданием нового типа контента?
Кажется немного излишним выполнять все пользовательское кодирование, необходимое для создания новой сущности, когда все функции CRUD и представлений уже встроены в типы контента.
7 answers
Дело не столько в преимуществах, сколько в том, что подходит для конкретной ситуации, как вы сказали. Вы можете представлять практически все, что угодно, с помощью узла, и в 99 % ситуаций (как я обнаружил, по крайней мере) вам не нужно будет реализовывать пользовательские типы сущностей.
Я всегда думаю о типе сущности taxonomy_term как о хорошем примере того, почему не все должно быть типом узла/содержимого:
Термин таксономии по существу предназначен для группировки различных сущностей и как таковой, он не требует той же функциональности, что и узел. Хотя вы могли бы теоретически использовать тип контента для выполнения этой функции (возможно, с полем ссылки на узел), термину таксономии не нужно делать то же самое, что и узлу, поэтому на самом деле это не имеет смысла. То же самое можно сказать и о типах сущностей user и taxonomy_vocabulary.
Таким образом, термин таксономии создается как отдельная сущность и запрограммирован на то, чтобы делать только то, что ему нужно, при этом все еще получая преимущества того, чтобы быть возможность прикреплять поля и т.д.
Я думаю, что простой ответ заключается в том, что когда тип узла/контента не делает то, что вам нужно, или это просто огромное количество излишних/накладных расходов для очень небольшой выгоды, тогда вам следует выбрать написание пользовательского объекта.
Это основано только на моем личном опыте; Мне было бы интересно услышать, что кто-то, непосредственно связанный с разработкой ядра Drupal, сказал об этом.
Очень простое эмпирическое правило, которое я использую, заключается в том, нужно ли публиковать ваш контент самостоятельно. Если да, то перейдите к узлу, если нет, выберите объект. Формы сущностей теперь позволяют создавать интерфейс для заполнения ваших сущностей.
Например, на веб-сайте, созданном с помощью D6, мы создаем тип рекламного контента (с его полем изображения, датой начала/окончания показа...), но затем вы должны сделать его не опубликованным по умолчанию и предоставить вашим редакторам права на редактируйте/просматривайте эти узлы и надеялись, что никакие просмотры/поиск не будут отображать их во внешнем мире. Это довольно громоздко, и было бы проще иметь дело с сущностями.
Сущность представляет конкретный вариант использования.
Я полагаю, что заслуга в этом простом определении принадлежит Фаго, но мне лень искать ссылку.
Мы могли бы использовать Content (он же Nodes) для всех вариантов использования, если бы захотели, но часто это не имеет смысла.
Content имеет автора и настройки как для комментариев, так и для расположения меню.
Users, представляют собой вариант использования, достаточно отличный от Content, потому что на user ни одно из вышеперечисленных не делает любой смысл, в то время как, с другой стороны, у user должен быть адрес электронной почты и пароль.
Taxonomy terms выделяются тем, что у них есть встроенная функциональность, которую можно расположить в иерархии, даже круговой.
Если ваш вариант использования достаточно похож на существующую сущность, продолжайте использовать эту сущность. Если ваша сущность управляется существенно иными правилами, чем любые существующие, создайте новый.
Существует также Введение в сущности , но, к сожалению, оно на самом деле это не ответ на ваш вопрос.
Я думаю, что все дело в контексте, узел в основном используется для контента, так что это будут блоги, статьи, часто задаваемые вопросы и т.д. В то время как пользователь для профилей, таких как персонал, клиенты и т.д. Пример того, когда вы можете создать новую сущность:
- Форум
- Проект (с точки зрения управления проектами)
- Форма
- Запрос в службу поддержки
- Группа
Хотя вы могли бы использовать узел для чего-то вроде заявки в службу поддержки, это может быть не лучший шаблон и значения по умолчанию... Надежда это помогает.
Сущности можно создавать с меньшими затратами, чем узлы, поскольку им не нужно обладать всеми мощными функциями, которыми обладают сущности.
Это также означает, что хранилище может быть проще - вы можете создать их, чтобы получить всю информацию в простом запросе без СОЕДИНЕНИЙ, если хотите. Все поля красиво расположены всего в одной аккуратной таблице.
Это может быть огромным преимуществом, если у вас есть много функций, которые должны выполнять запросы к сущностям, и вы обновляете множество сущностей одновременно с запросами на обновление базы данных. Если вы сможете убедиться, что данные относительно автономны в одной таблице, у вас будет меньше проблем и возможностей для повреждения данных.
Это подлежит обсуждению, и в конце концов вы должны принять свои решения как разработчик.
Я выбираю сущности вместо узлов, когда данные не должны быть общедоступными с их собственным URL-адресом. Узлы по умолчанию получают псевдоним URL, опубликованный статус, заголовок, мета-теги, ... в то время как сущности просто получают запись в базе данных.
"Я хочу иметь возможность добавлять как можно больше баннеров с текстом, а затем в блоге выбирать между одним из их"
- Тип контента будет "Блог"
- Пользовательской сущностью будет "Элемент баннера"
Тип контента предназначен для контента сайта. То есть каждый тип контента предназначен для публикации и отображения на сайте. Например, статья (из коробки) предназначена для отображения на первой странице.
Теперь предположим, что вы хотите создать что-то вроде формы заявления о приеме на работу или на квартиру. Очевидно, что вы не хотели бы публиковать чье-либо заявление о приеме на работу на своем веб-сайте. Кроме того, что, если бы вы хотели составить список контактов с клиентами/ведущими? Было бы вы хотите рискнуть тем, что эта информация может быть опубликована по ошибке на вашем веб-сайте? Лично я бы не стал.
Следовательно, модуль формы сущности, который обсуждался выше. Это позволяет вам создавать тип сущности, который не предназначен для содержимого. Однако эти типы сущностей доступны для любого модуля, который поддерживает такие сущности, как правила, представления и органическая группа, и это лишь некоторые из них.
А затем вы попадаете в Drupal Commerce, где продукты являются типами сущностей. В основном сущности позволяют разработчикам расширять Drupal способом, который никогда не предусматривался оригинальными разработчиками Drupal.