我正在尝试映射用户和个人资料类,如下所示:
public class User
{
public long ID { get; set; }
public string LoginName { get; set; }
public Profile Profile { get; set; }
}
public class Profile
{
//the ID is the same with User's ID
public long ID { get; protected set; }
public string NickName { get; set; }
public Gender Gender { get; set; }
}
因此,它们可以映射为一对一和组件关系。我发现有些人对组件进行评估并认为一对一是一种不好的做法,为什么呢?出于性能原因?但是在许多场景中它们被设计为两个独立的表(例如,asp.net2.0 Membership)。
我该如何选择?我应该考虑哪些方面?我知道组件意味着“价值对象”,但不是一种恩惠,但这是否意味着更多的东西?
ps:让我更加困惑的是,即使是现实世界中的一对一关系,也应该使用多对一的意见!
答案 0 :(得分:3)
此类的密钥应位于您的用例中。不要以ASP.NET Membership为例,因为它的设计非常糟糕。
您需要回答以下问题:
如果大多数问题都是正确的,那么你就可以很好地使用一对一(我不同意@Falcon;这实际上是一对一的合法用途之一)
否则,组件将正常工作。它没有ID,因此您可以删除该属性。
答案 1 :(得分:2)
你不应该使用。
您拥有不同数据库表中的用户和配置文件,但两者共享互斥的PK: 见http://jagregory.com/writings/i-think-you-mean-a-many-to-one-sir/
关系数据库的设计实践非常糟糕,它很混乱,并不一定会对关系施加约束。
您可以使用组件从凌乱的关系数据库中获取干净的对象模型,配置文件和用户数据都存储在同一个数据库表中,但它们应该在您的对象模型中分开(就像您想要的那样,从您的码)。可能不支持延迟加载,这将导致高数据库流量。
关于你的困惑: 只需阅读我提供的链接。从技术上讲,对于正确设计的数据库方案,您需要多对一,因为这是技术上可行的并且将被映射。我知道这令人困惑。如果您只需要映射一侧,请考虑引用而不是一对一。