JohnCoffey
@JohnCoffey
Учусь.

Обязанности паттерна 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 вариант лучше с точки зрения производительности - сразу получаем нужных юзеров.
Но, он какой-то более неуклюжий с точки зрения архитектуры, как мне кажется.

А как бы вы поступили?
  • Вопрос задан
  • 128 просмотров
Пригласить эксперта
Ответы на вопрос 1
sarapinit
@sarapinit
Точу водой камень
Если используется entityframework, то я бы сделал сервис который получает в конструкторе dbcontext и дополнительно ничего не городил. Потому что DbContext это уже UnitOfWork с репозиториями внутри.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы