return *i;
правильно, однако вы не можете вернуть 0 или любое другое подобное значение. Попробуйте сгенерировать исключение, если Клиент не найден в векторе.
Также будьте осторожны при возврате ссылок на элементы в векторе. Вставка новых элементов в вектор может сделать вашу ссылку недействительной, если вектор должен перераспределить свою память и переместить содержимое.
Вы не должны обрабатывать такую авторизацию проверяет в ваших репозиториях. Бизнес-правило типа «Этот пользователь требует X комментариев для публикации» на самом деле не является запросом к репозиторию, это свойство вашего пользователя.
Кроме того, в приложении очень часто выполняются вызовы авторизации, и вы действительно не хотите обращаться к базе данных каждый раз, когда требуется проверка.
Вы должны правильно загрузить эти разрешения в свой объект User, который затем кэшируется для текущего запроса, и использовать свой домен:
public class Service {
public void Save(Post post)
{
if(User.GetCurrentUser().HasEnoughCommentsToPost())
postRepository.Add(post);
}
}
Я бы сослался на другой репозиторий на верхнем уровне, например на уровень обслуживания
Я думаю, что в вашем случае авторизация является частью логики вашего домена. Поэтому я бы создал абстрактный класс или интерфейс под названием AuthorizationPolicy (возможно, вы сможете найти более подходящее имя ближе к своему домену) на моем уровне домена. Прежде чем вы вызовете метод в репозитории, клиент должен проверить, есть ли у него разрешение на основе политики.
Другое решение, поскольку интерфейс репозитория также является частью бизнес-логики, вы можете создать базовый класс для ваш репозиторий, который проверяет разрешения пользователя и делегирует остальное производным классам.
Реализация AuthorizationPolicy будет взаимодействовать с классом каталога, если вы хотите. Таким образом, два репозитория хорошо разделены.