Моделирование модели продукта в Grails

Question

Я изучаю личный проект Grails и хочу объединить модель домена для представления каталога продуктов. Я действительно не могу решить, как это сделать. У меня будет несколько различных категорий продуктов, хотя многие категории будут иметь только базовый набор свойств, которые будут использоваться во всех категориях (например, название продукта, описание продукта, цена и т. Д.). Однако некоторые продукты будут обладать дополнительными свойствами, характерными для их категории.

Я изучил технику модели атрибута сущности (EAV), которая обеспечивает очень расширяемое решение. И я рассмотрел маршрут использования явной модели наследования ОО, где у меня есть подклассы базового класса Product для представления любого продукта, который обладает дополнительными свойствами.

Очевидно, что второй подход менее расширяем - для добавления новой категории продукта потребуется новый объект и, вероятно, пользовательский вид/редактор для интерфейса. Однако, как разработчик, я думаю, что модель программирования значительно понятнее и логичнее кодировать.

Подход EAV позволит динамическую расширяемость, но приведет к более загадочной модели программирования и будет иметь служебные издержки производительности в БД (объединение сложных таблиц). Представления/редакторы на лицевой стороне могут быть динамически сгенерированы, чтобы включать любое количество настраиваемых атрибутов для категории продукта, хотя я уверен, что возникнут ситуации, когда такая динамическая генерация не будет достаточной с точки зрения удобства использования.

Когда я рассматриваю структуру, такую ​​как Grails, кажется, имеет смысл идти по пути создания явной модели наследования. Я не убежден, что такая структура, как Grails, будет соответствовать требованиям EAV так хорошо - многие преимущества Grails будут потеряны в сложности. Однако я не уверен, что этот подход будет масштабироваться практически по мере увеличения количества категорий товаров.

Мне было бы очень интересно услышать об опыте других людей с этим типом задач моделирования!

Answer 1

У меня была ситуация, подобная этому, и я пошел с решением наследования. В этом я знал, что у меня никогда не будет более 10 классов, поэтому я не беспокоился об экспоненциальном росте сложности. Хотя вам понадобятся представления и контроллеры для каждого класса, вы можете сделать некоторые вещи, чтобы уменьшить дублирование кода. Первое, что нужно сделать, это поместить весь общий код просмотра в шаблоны. Например, если все ваши классы будут иметь цену, имя и описание, код представления, который позволит отображать и редактировать это, следует помещать в шаблоны. Вместо того, чтобы повторяющиеся строки кода в каждом представлении вы можете просто сделать

<g:render template=”/baseView</g>render> 

Для получения дополнительной информации о шаблонах см http://www.grails.org/Tag+-+render Вторая вещь, которую я нашел полезным сделать, это переместить все общий код контроллера в класс и определить затворов что я мог бы позвонить из моего фактического контроллера. Это стало довольно уродливым, так как мой метод сохранения не только обеспечивал правильное использование полей базового класса, но также имел бы код для угловых случаев унаследованных классов. Оглядываясь назад, лучшим вариантом могло быть определение пользовательского поведения в качестве функций класса домена, который требовал его или использования службы. С учетом сказанного, введение кода в блокировки, которое можно было бы вызывать из контроллера, по-прежнему было полезным, так как это позволило бы мне иметь однострочное тело контроллера вместо 30 или 40. Если бы мне пришлось модифицировать код, относящийся к базовому классу, я мог бы его редактировать где были определены ограничения, и это изменение отразилось бы на всех моих контроллерах без изменения кода в фактическом исходном файле контроллера. Это оказалось весьма полезным и позволило мне редактировать код в одном месте вместо того, чтобы редактировать дубликат кода через 10 контроллеров.

Answer 2

Inheritance отлично работает с Hibernate и GORM.Рассмотрим usingtable-per-subclass сопоставление, поскольку вы не можете определить NOT NULL ограничения с (по умолчанию) table-per-hierarchy сопоставление наследования.

Вы также можете использовать composition для «не так» общего, но общего, атрибутов.

«Критерии для EAV: вам нужно вводить новые атрибуты без изменения модели данных?

На практике приложения, подобные вашей, используют комбинацию наследования и EAV.

Вы обеспокоены производительностью при запросе JOIN ed tables. Обычно это не проблема, если вы используете index столбцы, включенные в инструкцию SQL WHERE.
(GORM/Hibernate автоматически создаст внешние ключи, которые также важны.) (Учитывая, что имеются необходимые индексы и СУБД, которая обеспечивает достойный оптимизатор запросов (то есть PostgreSQL или SQL Server - возможно, не MySQL), вы можете выбрать из миллионов записей, используя 10 объединений за 50 миллисекунд или меньше.)

Наконец, в вашей проблеме был отличный, недавний discussion.