Question

我目前为每个数据库表创建一个存储库，并为列值（传递数据的对象）创建相应的数据类。

我最近开始使用一些一对一的关系，我不确定实现它们的最佳方法是什么。

例如

如果我有1：1关系的User表和UserSettings表。

// Data classes (Holds all the field value for the table)
    public class User
    {
        public int UserId { get; set; }
        public string Name { get; set; }       
    } 


     public class UserSettings
        {
            public int UserId { get; set; }
            public bool SomeSetting { get; set; }       
        }

问题：

我应该总是通过User对象来操作UserSettings对象，还是应该能够操作它们独立地？
我应该在UserSettings对象中包含主键字段吗？
我应该在User对象中存储对USerSettings对象的引用吗？
我是为用户和一个UserSettings制作两个repo的，还是处理用户回购中的所有内容。

Answer 1

“通过用户对象”究竟是什么意思？
恕我直言，没有。
你可以，但我认为你不应该。您有什么理由想知道这些设置属于哪个用户？唯一一次你想要知道的事情就是你坚持下去的时候。在您的数据库中，您需要知道UserSettings属于哪个用户。在你的模型中，我认为你可以通过单向关系来满足
您应该只为每个聚合根创建一个存储库，在您的情况下，“用户”可以是聚合根。 UserSettings -imho-甚至不是实体而是值对象。

Answer 2

我唯一一次发现聚合根之间的1：1关系是有用的，那就是当关系两侧的聚合根由不同的域管理时。他们必须共享相同的主键，因此如果它们都由同一个域管理，那么它们根据定义相同聚合根的一部分。我认为你需要从不同的角度来处理这个问题：

此应用程序仅存在User对象吗？
你是否一直希望如此？

如果User是完全位于此域内的概念，则没有理由拥有与UserSettings具有1：1关系的User aggretate根;您只需使User.Settings成为检索UserSettings User的方法即可。（当然，这就消除了对存储库的需求 - 当UserRepository温和UserSettings上的所有其他内容时，User负责User。{/ p>

但是，如果User最终会通知多个域的会话，那么UserSettings需要代表自己的域，即应用程序将使用的服务。然后，您非常需要将此应用程序的User与不同应用程序的UserSettings分开。 User并非特定于此应用，但UserSettings的{{1}}是。

注意 - 为了不在此时重构您的项目，如果上述问题1或2的答案为“否”，那么您使User成为同一域中的单独聚合根，以便在最终将{{1}}移动到其自己的域中时创建无缝转换。

Answer 3

我目前为每个数据库表创建一个存储库

...

//数据类（保存表的所有字段值）

您似乎采用自下而上（数据库优先/以数据库为中心）的方法，这在DDD中并不常见。正如Domain Driven Design所暗示的那样，您通常首先建模您的域，充实您的聚合，聚合根和实体。

聚合根通常有自己的存储库，而常规实体通常没有。要知道实体是否应该是聚合根，您必须问自己该对象是否将成为应用程序中的主要入口点之一，其中一组相关对象吸引它并且只能通过遍历它来获得。

用户是聚合根的明显候选者。相比之下，用户设置不是IMO的根，它属于用户的影响范围。我将它作为User Aggregate的一部分，并且只能通过遍历用户来获得。这意味着在User中引用UserSettings，但不一定相反。

Answer 4

我会问自己，UserSettings是否可以与关联用户一起存在，和/或User是否始终具有关联的UserSettings。如果是这样，那么UserSettings可以很容易地成为User聚合的一部分，而不是单独的聚合本身。在数据库中是的，它们很可能位于不同的表中，它们之间具有1：1的关系，但这是存储库实现的特定问题。您的域模型可以考虑用户的UserSettings部分。

存储库模式和1：1关系

4 个答案: