CalabongaА как вы считаете?
Репозиторий - это полная абстракция от системы хранения, а не только от конкретной РСУБД.

К примеру у нас в Абрикосе есть темы: https://www.wildapricot.com/membership-website-themes

С точки зрения хранения - это набор файлов. С точки зрения домена приложения - это корень агрегации Theme.
И вот ThemeRepository по указанной спецификации возвращает нужную тему: оригинальную, или кастомную.
Первая - это набор файлов, что изначально создали мы; последняя - это частично расширенная, или полностью переработанная клиентами.
И вот оригинальных тем относительно мало и они хранятся на машине локально, а кастомных относительно много и они хранятся на сетевой шаре.
И, как Вы понимаете, при каждом запросе собирать корень агрегации с диска, или с сетевой шары, это чертовски нагладно.
Поэтому реализован двухуровневый кэш: MemoryCache + Couchbase. Реализован он через шаблон Декоратор.
Подключается/отключается через IoC.

И при этом для вызывающего кода работа со всем этим выглядит как repository.GetTheme(specification) .
И это не изменится, если сетевая шара будет послана и заменена на микросервис писанный на Go, или на MongoDB GridFS

CalabongaЯ-то себе сделал nuget обобщенный
Гы... https://aspnetboilerplate.com/Pages/Documents/EntityFramework-Integration

CalabongaНо хочу тогда уточнить, что есть EntityFramework не реализует Pagination, Row Level Security и Model -> ViewModel mapping, то где реализуете данную логику если не используюте Repository???
One Domain-Driven-Design solution to the problem of where to place querying, sorting, and paging logic is to use a Specification .

https://deviq.com/specification-pattern/

hVosttCalabonga,

Посмотрел на нугет, перешёл на сайт, глянул исходники.
Я считаю, что разделение на ReadableRepositoryBase и Writeable это ошибка.
Репозиторий по своей сути, это набор методов:

GetById
Add
Remove
Update

Это идеальный во всех смыслах репозиторий. Отсадить выполнение запросов надо не в репозиторий "только для чтения" -- это немного асбурдно, так как репо хранит объекты, сущности, а результы запроса самые разные, далеко не сущности, а некие проекции, аггрегации, суммы, группировки. Это все не задачи репозитория.

Т.е. надо IRepository и типа IQueryService если уж на то пошло. IQueryService принимает либо Query Object, либо работает со спецификациями и позволяет теребонькать за IQueryable.
Мы же это вроде как обсуждали уже в мае

CalabongaА что касается "идельного", ты вы же сказали, что модно и без него если есть EF... :)
Можно вообще никакие паттерны не использовать в проекте, где есть EF, не пристрелят

CalabongaА то что сборка разбита на две части, это только плюс, потому что в зависимости от ролей пользователя он получит только то, что можно.В плане? Запретить какой-то роли писать, какой-то читать в рамках одного репозитория? Легко.

CalabongaОчень удобно инжектить.Один generic repository тоже очень удобно инжектить.

CalabongaДа реализация проще, например есть только сайты для чтения fate name.ru например.Дык реализуйте метод GetById, а в методах Add, Remove, Update киньте исключение: "Ай, ай, ай, у нас сайт только для чтения, какой суке понадобилось дёрнуть Add?!"

А вообще давно уже придумали CQS.