Шаблон репозитория и отношения 1: 1

Question

В настоящее время я создаю репозиторий для каждой таблицы базы данных и соответствующий класс данных для значений столбца (объект для передачи данных).

Недавно я начал использовать отношения 1: 1, и я не уверен, что будет лучшим способом их реализовать.

Например

Если у меня есть таблица User и таблица UserSettings в соотношении 1: 1.

// 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; }       
        } 

Вопросы:

1. Должен ли я всегда проходить через объект User, чтобы манипулировать объектом UserSettings, или я должен иметь возможность манипулировать ими независимо друг от друга?
2. Стоит ли включать поле первичного ключа в объект UserSettings?

3. Должен ли я хранить ссылку на объект USerSettings в объекте User?

4. Должен ли я сделать два репо по одному для User и один UserSettings, или я обработаю все в Репо пользователей.

Answer 1

Единственный случай, когда мне удалось найти соотношение 1: 1 между агрегатными корнями, - это когда агрегатные корни с обеих сторон взаимосвязи управляются разными доменами. Они должны совместно использовать один и тот же первичный ключ , и поэтому, если они оба управляются одним и тем же доменом, то они по определению являются частями одного совокупного корня . Я думаю, что вам нужно подойти к этому вопросу под другим углом:

1. Объект User будет существовать только для этого приложения?
2. Ожидаете ли вы, что так будет всегда?

Если User - это концепция, которая полностью находится внутри этой области, то нет никаких причин иметь совокупный корень UserSettings, который имеет отношение 1: 1 с User; вы просто делаете User.Settings способ получить UserSettings для этого User. (И, конечно, это устраняет необходимость в хранилище - UserRepository становится обязанностью гидратировать UserSettings, когда он гидратирует все остальное на User.)

Но, если User будет в конечном итоге информировать сеансы для нескольких доменов, то User должен представлять свой собственный домен , услугами которого будет пользоваться ваше приложение. Затем вы получаете очень реальную необходимость отделить UserSettings этого приложения от приложений другого приложения. User не является определенным для этого приложения, но UserSettings для этого User - это.

ПРИМЕЧАНИЕ - В целях отказа от рефакторинга вашего проекта на данный момент , если ответ на вопрос 1 или 2 выше - «нет», то вы должны делает UserSettings отдельным агрегированным корнем в том же домене, чтобы создать плавный переход, когда вы в конечном итоге переместите User в свой собственный домен.

Answer 2

В настоящее время я создаю репозиторий для каждой таблицы базы данных

...

// Классы данных (Содержит все значения поля для таблицы)

Кажется, вы применяете подход снизу вверх (база данных в первую очередь / база данных), что редко встречается в DDD. Как следует из названия «Domain Driven Design», вы обычно начинаете с моделирования своего домена, уточняя свои агрегаты, совокупные корни и сущности.

Совокупные корни обычно имеют собственный репозиторий, в то время как обычные сущности чаще всего этого не делают. Чтобы узнать, должен ли объект быть Агрегированным корнем, вы должны спросить себя, будет ли этот объект одной из основных точек входа в приложение, когда группа связанных объектов тяготеет к нему и доступна только через его прохождение.

Пользователь является очевидным кандидатом в Совокупный корень. Пользовательские настройки, напротив, не являются IMO-рутом, они относятся к сфере влияния пользователя. Я бы сделал его частью пользовательского агрегата и получить его только через обход пользователя. Это означает наличие ссылки на UserSettings в User, но не обязательно наоборот.

Answer 3

1. Что именно вы подразумеваете под «прохождением объекта пользователя»?
2. ИМХО, нет.
3. Вы можете, но я не думаю, что вы должны. Есть ли какая-то причина, по которой вы хотите узнать, к какому пользователю относятся настройки? Единственный раз, когда вы захотите это узнать - это когда вы упорствуете. В вашей базе данных вам нужно знать, к какому пользователю принадлежат пользовательские настройки. В вашей модели, я думаю, вам может быть достаточно однонаправленных отношений
4. Вы должны создавать репозиторий только для совокупного корня, в вашем случае «Пользователь» может быть совокупным корнем. UserSettings - это даже не сущность, а объект значения.

Answer 4

Я бы спросил себя, могут ли UserSettings существовать без ассоциированного пользователя, и / или всегда ли у User есть связанные UserSettings.Если это так, то UserSettings можно легко сделать частью совокупности пользователей, а не отдельной отдельной совокупностью.Да, в базе данных они, скорее всего, будут находиться в разных таблицах с соотношением 1: 1 между ними, но это особая проблема при реализации репозитория.Модель вашего домена может учитывать часть пользовательских настроек пользователя.