Обязанности паттерна Repository, как лучше организовать код?
Предположим, у нас есть таблица с пользователями Users.
У юзера есть дата окончания его работы в системе (ExpirationDate).
Есть таблица с уведомлениями для юзеров UserNotifications.
У уведомления есть поле c типом (TypeId).
Есть класс (отдельное приложение), который каждый день ищет юзеров, у которых через месяц заканчивается его срок работы в системе и для таких юзеров создает уведомление определенного типа (пусть будет TypeId = 1).
Напр. "Ваш срок работы в системе заканчивается 01.07.21... "
Соответственно, этим классом должна быть проделана следующая логика --
Найти всех юзеров, у которых через месяц закончится срок работы.
Создать для них уведомление, ТОЛЬКО при условии, что уведомления с таким типом у юзера еще нет.
Если я правильно понимаю, тут могут быть примерно такие варианты решения:
1 Вариант:
1) С помощью метода UserRepository найти всех юзеров, у которых ExpirationDate заканчивается через месяц.
2) С помощью метода UserNotificationRepository узнать, есть ли уже в БД для этого юзера уведомление с таким типом.
3) Если такого уведомления нет => создать его с помощью метода UserNotificationRepository
2 Вариант:
1) В методе UserNotificationRepository (или методе UserRepository ?) одним запросом найти тех юзеров, у которых ExpirationDate заканчивается через месяц + в БД для этого юзера нет уведомление с таким типом.
2) создать его с помощью метода UserNotificationRepository
-------------
1 вариант мне нравится больше с архитектурной точки зрения - каждый репозиторий отвечает за свои прямые обязанности, в них не замешана бизнес логика... минус в том, что придется на клиент из бд грузить тех юзеров, для которых уже есть уведомление, и только потом фильтровать их...
2 вариант лучше с точки зрения производительности - сразу получаем нужных юзеров.
Но, он какой-то более неуклюжий с точки зрения архитектуры, как мне кажется.
2) С помощью метода UserNotificationRepository узнать, есть ли уже в БД для этого юзера уведомление с таким типом.
3) Если такого уведомления нет => создать его с помощью метода UserNotificationRepository
Зачем это проверять снаружи? Почему бы просто не сделать один метод для отправки уведомлений, который внутри проверит, не было ли оно отправлено раньше?
1. Нужно из репозитория получить объекты юзеров, которые удовлетворяют условиям появления этого типа уведомления (срок работы заканчивается) и для которых еще нет уведомления такого типа...
2. Используя определенные данные модели юзера, создать для всех этих юзеров уведомление этого типа..
Я понимаю, что задача несложная, можно реализовать многими разными способами, интересно просто как правильно поступить с учетом принципов проектирования..
Ну то есть в моём понимании, здесь есть несколько потенциальных точек для изменения -- логика поиска пользователя, логика создания уведомления И хочется, чтобы эти логики были отделены друг от друга, и, чтобы бизнес логика не смешивалась с логикой доступа к данным (
Если используется entityframework, то я бы сделал сервис который получает в конструкторе dbcontext и дополнительно ничего не городил. Потому что DbContext это уже UnitOfWork с репозиториями внутри.
Простой
