Відповіді:
Справа не стільки в тому, які переваги, скільки в тому, що підходить для конкретної ситуації, як ви сказали. Ви можете представляти майже все з вузлом, і для 99% ситуацій (як я принаймні знайшов) вам не потрібно буде реалізовувати власні типи сутності.
Я завжди вважаю taxonomy_termтип сутності як хороший приклад того, чому не все повинно бути типом вузла / вмісту:
Термін таксономії по суті є для групування різних об'єктів і як такий не вимагає тієї ж функціональності, як вузол. Хоча теоретично ви можете використовувати тип вмісту для виконання цієї функціональності (можливо, з полем опорного вузла), термін таксономії не повинен робити те саме, що і вузол, тому це не має сенсу робити. Те саме можна сказати для типів userта taxonomy_vocabularyтипів.
Отже, термін таксономії створюється як окрема сутність і запрограмований на те, щоб робити лише те, що потрібно, при цьому отримуючи переваги від можливості мати поля, прикріплені тощо.
Я думаю, що проста відповідь полягає в тому, що коли тип вузла / вмісту не робить те, що вам потрібно, або це просто величезна кількість перевитрат / накладних витрат за дуже малу користь, то вам слід вибрати запит на замовлення.
Це базується лише на моєму особистому досвіді; Мені було б цікаво почути, що про це мав сказати хтось, безпосередньо причетний до розвитку ядра Drupal.
Я використовую дуже просте правило: чи потрібно вміст публічно відображатися самостійно. Якщо так, то перейдіть до вузла, якщо не виберіть сутність. Entityforms тепер дозволяє створити інтерфейс для заповнення ваших сутностей.
Наприклад, на веб-сайті, створеному за допомогою D6, ми створюємо тип вмісту реклами (з полем зображення, початком / кінцевою датою відображення ...), але тоді ви повинні зробити його не опублікованим за замовчуванням і дати редакторам права редагувати / перегляньте цей вузол і сподіваєтесь, що перегляди / пошук не відображатиме їх у зовнішньому світі. Це досить громіздко, і було б легше мати справу з сутностями.
Суб'єкт господарювання представляє конкретний випадок використання .
Я вважаю, що заслуга в цьому простому визначенні припадає на Фаго , але я лінуся знайти посилання.
Ми могли використовувати Content(ака Nodes) для всіх випадків використання, якщо б хотіли, але часто це не має сенсу.
Content має автора та налаштування як коментарів, так і розташування меню.
Users, представляють собою випадок використання, який досить відрізняється від того, Contentщо userні в одному з перерахованих вище немає сенсу, а з іншого боку, userелектронний лист та пароль повинні мати електронну пошту та пароль.
Taxonomy terms виділяються тим, що вони мають вбудовану функціональність, яку можна розташувати в ієрархії, навіть круговій.
Якщо ваш випадок використання достатньо схожий з існуючим об'єктом, перейдіть із використанням цього об'єкта. Якщо ваша організація керується значно іншими правилами, ніж усі існуючі, створіть нове.
Також є вступ до організацій , але, на жаль, це не відповідає на ваше запитання.
Я думаю, що це стосується контексту, вузол багато в чому використовується для вмісту, щоб це були блоги, статті, файли тощо. Хоча користувач для таких профілів, як персонал, клієнти тощо.
Хоча ви могли б використовувати вузол для чогось, як квиток підтримки, це може бути не найкращим шаблоном та типовими налаштуваннями ... Сподіваюся, що це допомагає.
Суб'єкти можуть бути створені з меншими накладними витратами, ніж вузли, оскільки їм не потрібно мати всіх важких функціональних можливостей, які мають суб'єкти.
Це також означає, що зберігання може бути простішим - ви можете побудувати їх, щоб захопити всю інформацію в простому запиті без ПРИЄДНАННЯ, якщо хочете. Всі поля красиво лише в одному охайному столі.
Це може бути величезною вигодою, якщо у вас є багато функцій, для яких потрібно робити запити на об'єкти, і ви оновлюєте безліч сутностей одночасно із запитами UPDATE до бази даних. Якщо ви можете переконатися, що дані відносно містяться в одній таблиці, у вас менше турбот і можливостей пошкодження даних.
Тип вмісту призначений для вмісту сайту. Тобто кожен тип контенту призначений для публікації та появи на сайті. Наприклад, стаття (поза скринькою) призначена для відображення на першій сторінці.
Скажімо, ви хочете створити щось на зразок форми заявки на роботу або квартиру. Очевидно, ви б не хотіли публікувати чиюсь заяву на працевлаштування на своєму веб-сайті. Крім того, що робити, якщо ви хотіли скласти список контактів із клієнтами та клієнтами? Ви хочете ризикнути, що ця інформація може бути опублікована помилково на вашому веб-сайті? Особисто я б не став.
Отже, модуль форми образу, про який йде мова вище. Це дозволяє створити тип сутності, який не призначений для вмісту. Однак ці типи сутностей доступні будь-якому модулю, який підтримує такі об'єкти, як правила, представлення та органічна група, щоб назвати лише кілька.
А потім ви потрапляєте в Drupal Commerce, де продукція є типовими формами. В основному організації дозволяють розробникам розширювати Drupal так, як ніколи не передбачалося оригінальними дизайнерами Drupal.
Це підлягає обговоренню, і врешті-решт ви повинні приймати рішення як розробник.
Я вибираю об'єкти над вузлами, коли дані не мають бути загальнодоступними за допомогою їх власного URL-адреси. Вузли за замовчуванням отримують псевдонім URL-адреси, опублікований статус, заголовок, метатеги, ... а суб'єкти просто отримують запис у базі даних.
"Я хочу мати можливість додати якомога більше банерів з текстом, а потім у блозі вибрати один із них"
Entity vs Content
У сутності є сукупності сутностей, у яких є поля
Вміст - це тип Сутності. Тому,
Вміст містить пакети вмісту (стаття, сторінка), які містять поля (тіло, зображення статті)
Якщо ви програміст, ви, безумовно, обираєте шлях створення власної сутності, але для будівельників сайтів це може бути не найкращим шляхом. Знову для розробників сайтів є інтерфейс для створення Entity http://drupal.org/project/eck