Если я правильно понял, ядром приложения, разрабатываемого с использованием подхода Clean Architecture, являются сущности (Entities). Сущности являются бизнес объектами приложения и содержат самые общие и высокоуровневые правила. Насколько я понял, в сущностях не совсем правильно указывать вторичные ключи (например, userId) и вообще, сущности не являются моделями для ORM. Получается, что если в сущности есть ссылка на пользователя, мы просто добавляем в нее поле типа User. Никаких Id нету, за исключением Id самой сущности. В связи с этим у меня возникает вопрос, который я постараюсь описать в следующем примере.
Допустим, необходимо разработать приложение - список задач. Есть сущности User (пользователь), Task (задача) и Tag (тег). Каждая задача может содержать набор тегов + каждая задача связана с конкретным пользователем. Теги задачи не должны дублироваться. Получается, что в коде будем иметь что-то подобное:
class Task {
// ...
public string Text{ get; private set; }
public User Creator { get; private set; }
public IList<Tag> Tags { get; private set; }
// ...
public void AddTag(Tag tag) {
// есть ли у задачи такой тег: если нет - добавляем
}
}
class Tag {
// ...
public string Name { get; private set; }
// ...
}
В приведенном примере есть проблема: получается, что для проверки того факта, что теги не дублируются, их необходимо выгрузить из БД и произвести маппинг с модели ORM на сущность.
Собственно вопрос: если мы работаем с сущностью, которая содержит коллекцию других сущностей, каким образом выполнять проверку правил в отношении коллекций, при этом не выгружая все данные из БД?
Средний
Сложный
