CalabongaА как вы считаете?

Вообще, при использовании EF, лепить сверху паттерн Репозиторий совсем не обязательно. В этом есть как и плюсы, так и минусы. Если вы совершенно точно никогда за рамки EF в своих проектах не выйдите, и за рамки одной единственной БД, то не нужен вам этот репозиторий.

Calabonga,

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

Конечно совсем по феншую это CQS, и отказ от EF, в пользу команд и запросов. Но это дорого на начальном этапе.

CalabongaВ общем-то, идея понятна. Но хочу тогда уточнить, что есть EntityFramework не реализует Pagination, Row Level Security и Model -> ViewModel mapping, то где реализуете данную логику если не используюте Repository??? Я-то себе сделал nuget обобщенный репозиторий.

EF реализует Pagination через интерфейсы IQueryable Take/Skip.

В обязанности репозитория не входит обеспечение Row Level Security, реализовывать его там -- вколачивать кривые ржавые костыли.

Посмотри паттерн Спецификация и его реализации на IQueryable (гуглится на раз). Это то, что тебе нужно для сесурыти )

Model -> ViewModel должен делать контроллер, с помощью AutoMapper, например. Это его задача, а не репозитория, который совершенно точно не должен знать и понятий иметь ни о каких вью моделях.

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

В общем, кто во что горазд.

Поэтому, на не больших проектах и даже средненьких можно легко обходится без доп. слоя репо, так как EF им и является. А в больших EF и не нужен вовсе

Calabonga,

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

GetById
Add
Remove
Update

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

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

skyANAМы же это вроде как обсуждали уже в мае

Повторение матерь учения :)

CalabongaВыставлять IQueryable наружу это мовитон, ибо с юнит тестами к нему не подлезешь.

Честно говоря, сколько слышу по моветоновость IQueryable, так и не увидел ни одного примера с ним, где могут быть проблемы. Тестировать IQueryable совсем не сложно, вариантов несколько, от тупого List, который сидит за IQueryable, до разбора выражения, но это уже паранойя :)

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

Отделять чтение от записи, это правильно, поэтому придумали CQS. Но у вас не CQS, вы просто распилили интерфейсы, без видимого профита. И запросы у вас нельзя писать отдельно. Нельзя собирать запросы из частей, например, взять спецификации безопасности и дополнить бизнес-фильтрами так, чтобы это можно было писать, сопровождать и тестировать по-отдельности. У вас нельзя.

Учитывая, что в EF запись ведётся через трекинг, ваши интерфейсы WriteOnly не имеют смысла абсолютно. На EF без проекций вообще нельзя сделать адекватный CQS.

Очень плохо, что вы вью-модели протащили на уровень репозитариев. Это прям кричащее нарушение всех принципов проектирования.

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

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

CalabongaДумаю вам нужно ознакомиться с плюсами и минусами выставления наружу IQueryable. Не все так гладко в этом вопросе.

За всю свою практику в десятках проектов от больших и малых, я никаких минусов не увидел. Это замечательный интерфейс, с которым удобно работать и который прячет подробности реализации: на IQueryable может быть как List, так и БД. Да, его можно скрыть за спецификациями, и это будет в плюс. Но плюс будет в том, что вы таким образом сможете комбинировать запросы, писать и сопровождать их отдельно, также исправлять и дорабатывать эти запросы, без необходимости ковыряться в прикладном коде.

Calabonga,

Если исходников нет, хотя бы сгенерируйте документацию АПИ, это не сложно.

Calabonga,

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

А потом заюзать тулузу, например такую: https://dotnet.github.io/docfx/

LessypТолько куда-же GetCustomerByName() то делись

оформились в спецификацию, например, CustomerByNameSpecification

но не нужно путать это с фильтрацией

skyANA,

это закрытая вендорная разработка

Lessyp,

1. не знаю, с чего вы это решили
2. нужно понять что такое репозиторий для начала, почитать у Фаулера, а то все "знают", а на деле нет ни знаний, ни понимания.

Lessyp,

не будет зацементированности.

давайте я приведу каноничную реализацию репозитория:

FindById
Add
Update
Delete

всё. а где, спросите, GetAll, GetList, GetQuery....
можно найти массу решений, и даже примеры в статьях, где подобные методы есть.
но это неправильно.

в CQRS, вообще ничего такого нет от слова совсем.
а где, где же вот это вот всё?
ответ: Query Object, можно посмотреть в чужих исходниках вариации на тему QueryProcessor, QueryHandler etc.

если это не CQRS, то может быть добавлен ещё один метод

GetBySpecification

а ещё, не забываем про пейджинг. его нужно закладывать изначально для всех.
да, даже для долбаных справочников, где _НУ_СОВЕРШЕННО_ТОЧНО_НИКОГДА!!__ не будет больше 3-х записей. дичайшие нарушения, за которые надо руки по шею отрывать, начинаются вот с таких тупейших посылов.