为不同类别的用户偏好建模的类别设计问题
我不确定如何在我的应用程序中设计几个类。 基本上是这样一种情况：
- 每个用户可以有许多偏好，
- 每个偏好可以引用不同类别的对象（例如专辑、电影、书籍等），
- 偏好被表示为一组值（例如分数等）。
问题是许多用户可以对相同的对象有偏好，例如：
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
}
并实现所有这些类。 这可以工作，但它看起来很丑陋，并且需要大量的连接才能工作。 你有一些我可以用来很好地建模的模式吗？
干杯， 穆隆
I'm not sure how to design a couple of classes in my app.
Basically that's a situation:
- each user can have many preferences
- each preference can be referred to an object of different classes (e.g. album, film, book etc)
- the preference is expressed as a set of values (e.g. score, etc).
The problem is that many users can have preferences on the same objects, e.g.:
John: score=5 for filmid=apocalypsenow
Paul: score=3 for filmid=apocalypsenow
And naturally I don't want to duplicate the object film in each user.
So I could create a class called "preference" holding a score and then a target object, something like:
User{
hasMany preferences
}
Preference{
belongsTo User
double score
Film target
Album target
//etc
}
and then define just one target.
Then I would create an interface for the target Classes (album, film etc):
Interface canBePreferred{
hasMany preferences
}
And implement all of those classes.
This could work, but it looks pretty ugly and it would requires a lot of joins to work.
Do you have some patterns I could use to model this nicely?
Cheers,
Mulone
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
偏好与用户和对象都有关系。用户可能表达一种或多种偏好。可能存在对某个对象表达的一种或多种偏好。
用数据建模的术语来说，用户与偏好之间存在 0 到 N 的关系，而对象与偏好之间存在 0 到 N 的关系。
首选项应该是与用户和对象不同的类。
The preferences have a relationship with both the users and the objects. There may be one or more preferences expressed by a user. There may be one or more preferences expressed about an object.
To put it in data modeling terms, user has a 0 to N relationship with preferences, and object has a 0 to N relationship with preferences.
The preferences should be a separate class from the users and the objects.
我更喜欢创建诸如
IPreferrable之类的接口的概念，我相信 Grails 中通过 Groovy 基础支持该接口。我同意首选项应与用户对象分开，但如果其他对象有效地代表您的首选项分类，则您可以在构建首选项对象图时重用它们。从领域建模的角度来看，您提出的建议没有任何问题，但用户对象可能会变得相当庞大。从持久性的角度来看...因为这些只是首选项，所以您可以将整个首选项对象图序列化为 XML。根据您的数据库引擎，您可以使用 SQLXML，这意味着您仍然可以通过 XQuery / XPath 获得本机 XML DOM 类型和本机查询支持。这样做不应避免避免正确的数据库设计，但在某些情况下是合理的。考虑到所有这些，从性能角度来看，（反）序列化总是更加昂贵，尽管转换为 JSON 对象、元标记结构和其他格式变得更容易。当然还有其他方法可以解决这个问题，但既然您想要替代方案，这只是又一个选择。
I prefer the notion of creating an interface such as
IPreferrablewhich I believe is supported in Grails via the Groovy foundation. I agree that the preferences should be seperated from the user object, but if the other objects effectively represent your preference taxonomy, you may be able to reuse them when building the preference object graphs. From a domain modeling perspective there is nothing wrong with what you proposed, but the user object can become fairly hefty.From a persistance stand-point... since these are just preferences you may be able to get away with serializing the entire preferences object graph to XML. Depending on your database engine you can use SQLXML which means you still native XML DOM types and native query support via XQuery / XPath. This should not be done to avoid proper database design but is reasonable in some cases. With all that in mind, (de)serialization is always more expensive from a performance perspective, although transformation to things like JSON objects, Meta tag structures, and other formats becomes easier. There are certainly other ways to deal with this, but since you wanted alternatives this is just one more option.