Проблема с дизайном класса для моделирования пользовательских предпочтений для разных классов

Я не уверен, как разработать пару классов в моем приложении. В общем такая ситуация:

  • каждый пользователь может иметь много предпочтений
  • каждое предпочтение может быть отнесено к объекту разных классов (например, альбому, фильму, книге и т. д.)
  • предпочтение выражается в виде набора значений (например, оценка и т. д.).

Проблема в том, что многие пользователи могут иметь предпочтения для одних и тех же объектов, например:

John: score=5 for filmid=apocalypsenow 
Paul: score=3 for filmid=apocalypsenow

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

Таким образом, я мог бы создать класс под названием «предпочтение», содержащий оценку, а затем целевой объект, что-то вроде:

User{ 
  hasMany preferences 
} 

Preference{ 
  belongsTo User 
  double score 

  Film target   
  Album target 
  //etc 
}

а затем определить только одну цель. Затем я бы создал интерфейс для целевых классов (альбом, фильм и т. д.):

Interface canBePreferred{ 
  hasMany preferences 
}

И реализовать все эти классы. Это может сработать, но выглядит довольно уродливо, и для работы потребуется много объединений. У вас есть шаблоны, которые я мог бы использовать, чтобы красиво смоделировать это?

Привет, Мулоне


grails design-patterns class-design
person Mulone    schedule 17.05.2010    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Предпочтения связаны как с пользователями, так и с объектами. Может быть одно или несколько предпочтений, выраженных пользователем. В отношении объекта может быть выражено одно или несколько предпочтений.

Говоря языком моделирования данных, пользователь имеет отношение от 0 до N с предпочтениями, а объект имеет отношение от 0 до N с предпочтениями.

Настройки должны быть отдельным классом от пользователей и объектов.

person Gilbert Le Blanc    schedule 17.05.2010
comment
Спасибо! Есть ли элегантный способ смоделировать отношения с разными классами? Теперь я бы сделал это с разными участниками: Film targetFilm Album targetAlbum и т. д. Но это довольно некрасиво и требует логики. Есть идеи? - person Mulone; 17.05.2010
comment
кроме того, можно ли использовать интерфейсы в Grails? Я не мог найти документ об этом. - person Mulone; 17.05.2010
comment
Извиняюсь. Я занимаюсь моделированием данных, а не разработчиком Grails. Что касается вашего объекта, у вас может быть один огромный класс, в котором есть все элементы всех различных объектов, которые вы хотите смоделировать. Немного расточительно по пространству, но концептуально проще. Или у вас может быть базовый класс объектов, определяющий общие элементы, и ваши классы фильмов и альбомов наследуют базовый объект и определяют элементы, характерные для фильмов и альбомов, соответственно. - person Gilbert Le Blanc; 17.05.2010
comment
Ваши таблицы базы данных будут отражать структуру вашего класса. Либо одна огромная таблица объектов, либо базовая таблица с общими элементами и дочерние таблицы с элементами, характерными для каждого типа объекта. - person Gilbert Le Blanc; 17.05.2010
comment
Таблица предпочтений будет иметь связь с таблицей базовых объектов. Базовая таблица объектов будет иметь родительскую связь с другими таблицами объектов. - person Gilbert Le Blanc; 17.05.2010

arrow_upward
0
arrow_downward

Я предпочитаю идею создания интерфейса, такого как IPreferrable, который, как я полагаю, поддерживается в Grails через основу Groovy. Я согласен с тем, что предпочтения должны быть отделены от пользовательского объекта, но если другие объекты эффективно представляют таксономию ваших предпочтений, вы можете повторно использовать их при построении графиков объектов предпочтений. С точки зрения моделирования предметной области в том, что вы предложили, нет ничего плохого, но пользовательский объект может стать довольно здоровенным.

С точки зрения постоянства... поскольку это всего лишь настройки, вы можете избежать сериализации всего графа объектов настроек в XML. В зависимости от вашего ядра базы данных вы можете использовать SQLXML, что означает, что вы по-прежнему используете собственные типы XML DOM и собственную поддержку запросов через XQuery / XPath. Этого не следует делать, чтобы избежать неправильного проектирования базы данных, но в некоторых случаях это разумно. Имея все это в виду, (де)сериализация всегда дороже с точки зрения производительности, хотя преобразование в такие вещи, как объекты JSON, структуры метатегов и другие форматы, становится проще. Конечно, есть и другие способы справиться с этим, но, поскольку вам нужны альтернативы, это всего лишь еще один вариант.

person JoeGeeky    schedule 18.05.2010