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

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

0 голосов
/ 17 мая 2010

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

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

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

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

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

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

User{ 
  hasMany preferences 
} 

Preference{ 
  belongsTo User 
  double score 

  Film target   
  Album target 
  //etc 
}

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

Interface canBePreferred{ 
  hasMany preferences 
}

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

Cheers, Mulone

Ответы [ 2 ]

0 голосов
/ 18 мая 2010

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

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

0 голосов
/ 17 мая 2010

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

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

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

...