2009-07-27 4 views
10

У меня есть два каталога хранилища и пользователя, у меня есть ситуация, когда мне нужно вызвать метод в репозитории каталога из пользовательского репо, это хорошая практика или есть лучший способ?Вызов репозитория из репозитория

+0

Проблема. У меня есть методы, связанные с комментариями в моем репозитории каталога. В моем пользовательском репо я хочу добавить метод canuserpost (который будет запрашивать db, чтобы увидеть, достаточно ли сделано комментариев, чтобы они могли публиковать сообщения). Требуемый код будет использоваться в обоих репо, где он будет идти, в одном и ссылаться на другой, как на ссылку dfa на уровне обслуживания, так и на что-то еще? – monkeylee

ответ

9

Вы не должны обработки этих видов проверок авторизации в ваших репозиториях. Бизнес-правило, такое как «Этот пользователь требует, чтобы комментарии X были опубликованы» на самом деле не является репозиториемным запросом, это свойство вашего Пользователя.

Кроме того, вызовы авторизации выполняются очень часто в приложении, и вы действительно не хотите ударять свою базу данных каждый раз, когда требуется проверка.

Вы должны правильно загрузить эти разрешения в ваш объект пользователя, который затем сохраняется в кэше для текущего запроса, и использовать свой домен:

public class Service { 

    public void Save(Post post) 
    { 
     if(User.GetCurrentUser().HasEnoughCommentsToPost()) 
      postRepository.Add(post); 
    } 

} 
+0

+1 для хорошего примера – dfa

+0

Я думаю, что метод Save должен быть методом класса пользователя. Но тогда класс User должен знать о postRepo. Это хорошая идея? – mayu

6

Я хотел бы сослаться на другой репозитории в верхнем слое, например, как слой службы

0

Я думаю, что в вашем случае разрешение является частью домена логики. Поэтому я бы создал абстрактный класс или интерфейс под названием AuthorizationPolicy (возможно, вы можете найти лучшее имя ближе к вашему домену) в моем домене. Прежде чем вы вызовете метод в репозитории, клиент должен проверить, имеют ли они разрешение на основе политики.

Другое решение, поскольку интерфейс репозитория также является частью бизнес-логики, вы можете создать базовый класс для своего репозитория, который проверяет разрешения пользователя и делегирует остальные производным классам.

Реализация AuthorizationPolicy будет вести переговоры с классом Catalog, если вы хотите. Таким образом, два хранилища хорошо развязаны.

Смежные вопросы