2

我正在尝试映射类用户和配置文件，如下所示：

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

4

2 回答 2

3

关键应该在这个类的用例中。不要以 ASP.NET Membership 为例，因为它的设计很糟糕。

你需要回答这些问题：

  1. 个人资料作为其自身的实体是否有意义？
  2. 您是否在域中的其他任何地方引用了个人资料？
  3. 您可以拥有没有个人资料的用户吗？
  4. 它有自己的行为吗？
  5. 您会出于某种原因扩展（继承）个人资料吗？
  6. 大多数用例是否只处理用户（及其登录名，而不仅仅是 ID）而不是配置文件？

如果大多数问题都是正确的，那么您就有很好的理由使用一对一（我不同意@Falcon；这实际上是一对一的合法用途之一）

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

于 2010-12-02T18:15:59.527 回答
2

你不应该使用。

一对一

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

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

零件

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

参考

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

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

于 2010-12-02T16:17:05.373 回答