сущностей с помощью domain invariants, насколько актуален и релевантный данный подход организации в реальных проектах с использованием EF Core ? Такой подход как на скрине не всегда выгоден, так в книге говориться.
а какой подход будет всегда выгоден?
Мне кажется все от ситуации зависит
Просто интересно каким ещё образом можно выстроить отношения, указанные на скриншоте
В книге говориться что не обязательно дергать весь лист, если нам нужно в сущности поменять какие-то данные. Предлагается делать отношение следующем образом, создавать агрегатор который умеет работать с сущностью и также он является входной точкой для работы с ней, а связи выстраивать между агрегаторами. То есть не Лист делать, а создать Guid данной записи, а в другой таблице будет лежать уже данные связанные с этим Guid-ом. И если нам потребуется список для его обработки, то мы у сущности берем Guid и делаем запрос в сущность где лежат данные по этому guid-у
то есть я храню не список связанных сущностьей а список гуидов и когда нужно по гуиду дёргаю из бд тот связанный объект, всё это скрыто под абстракцией, так выходит?
Т.е. у вас сущности в БД = сущности БЛ?
Нее , смотри у тебя есть сущность человек и имущество, связь один ко многим и в таком варианте концепция предлагает не хранить в объекте человек список его имущества, а хранить его(человека) гуид, а сущность с имуществом кроме всех его свойств , хранить еще и id человека которому принадлежит данное имущество. И теперь если нам потребуется изменить данные у человека, то данные по его имуществу не подтянуться, а если нужно изменить что-то в его имуществе, то мы смотрим гуид человека и делаем запрос на имущество с фильтрацией по гуид
Когда как, но чаще да. А вы что, мапингом занимаетесь туда-сюда постоянно?
Если есть развитая БЛ, то я всегда ее держу отдельно от БД, а БД всегда в условно другом слое.
Что такое БЛ для начала ? )
Обсуждают сегодня