Question

我正在尝试映射用户和个人资料类，如下所示：

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：让我更加困惑的是，即使是现实世界中的一对一关系，也应该使用多对一的意见！

Answer 1

此类的密钥应位于您的用例中。不要以ASP.NET Membership为例，因为它的设计非常糟糕。

您需要回答以下问题：

配置文件作为自己的实体是否有意义？
您是否在域中的其他任何位置引用了个人资料？
您是否有没有个人资料的用户？
它有自己的行为吗？
您会因某种原因扩展（继承）个人资料吗？
大多数用例只是处理用户（及其LoginName，而不仅仅是ID）而不是个人资料？

如果大多数问题都是正确的，那么你就可以很好地使用一对一（我不同意@Falcon;这实际上是一对一的合法用途之一）

否则，组件将正常工作。它没有ID，因此您可以删除该属性。

Answer 2

你不应该使用。

一对一的

您拥有不同数据库表中的用户和配置文件，但两者共享互斥的PK：见http://jagregory.com/writings/i-think-you-mean-a-many-to-one-sir/

关系数据库的设计实践非常糟糕，它很混乱，并不一定会对关系施加约束。

组件

您可以使用组件从凌乱的关系数据库中获取干净的对象模型，配置文件和用户数据都存储在同一个数据库表中，但它们应该在您的对象模型中分开（就像您想要的那样，从您的码）。可能不支持延迟加载，这将导致高数据库流量。

参考

Imho，您应该使用参考。它的概念有点像一对一，但用户引用了一个配置文件。配置文件可以存储在自己的表中，可以延迟加载（性能），而不依赖于用户。

关于你的困惑：只需阅读我提供的链接。从技术上讲，对于正确设计的数据库方案，您需要多对一，因为这是技术上可行的并且将被映射。我知道这令人困惑。如果您只需要映射一侧，请考虑引用而不是一对一。

在NHibernate中选择一对一和组件

2 个答案:

一对一的

组件

参考