Как запретить использование репозиториев?

Question

Давайте представим себе следующий контур (я предположил, что мы используем ASP.NET MVC, но это не имеет большое значение для этого вопроса)

1. Мы репозитории, которые используются непосредственно из контроллеров

2. Некоторые из методы репозиториев необходимо обрабатывать определенным образом, комбинировать, кэшировать и т. д. Поэтому мы создаем службы для этих случаев. Итак, теперь некоторые методы репозиториев должны быть доступны из служб, но не напрямую. Каковы способы управления методами репозиториев, которые используются в нужном месте?

я вижу следующий образ:

Не использовать репозитории непосредственно на всех - использовать их только от услуг (мы даже можем сделать хранилища внутренними и видимыми только услуги по монтажу). Но в этом случае мы должны создавать обертки методов repostories даже для методов, которые могут быть использованы непосредственно из репозиториев.

Но я уверен, что есть более интересные, красота и гибкие способы реализации его ...

Answer 1

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

Однако это не то, что я делаю в своем приложении в очень похожей ситуации. В нашем приложении есть классы DAL (Data Access Layer) и классы BAL * Business Access Layer. Однако подавляющее большинство вызовов не требуют каких-либо бизнес-правил. Из 25 DAL нам действительно нужны только 3 BAL. Таким образом, остальные 22 BAL будут просто классами фасад/прокси.

Чтобы обойти это, мы определили интерфейс, который реализуется всеми нашими классами DAL/BAL (по одному для каждого типа). Таким образом, для UserDal и UserBal реализуют IUser (или UserBal может отсутствовать полностью, как это имеет место для пользователей).

Затем мы используем отражение реализовать следующий метод:

BalFactory.GetClass<IUser>() 

Каким будет выглядеть для реализации IUser в пространстве имен БАЛА, и если он не находит, то он возвращает реализацию IUser из DAL. Затем, если нам когда-либо понадобится добавить класс BAL позже, когда у нас его не было, мы просто должны добавить его в пространство имен BAL с соответствующим интерфейсом, и он автоматически будет выбран и использован.

Мы начали использовать это в приложении около четырех лет назад с отражением, и мы были очень довольны этим. Сегодня вы можете сделать это еще проще с MEF, я думаю.