но если норм адаптер надо написать для хуевастых репозиториев с либ - то норм

Согласен

Юрий пропаганду ввел

я думаю проблема не в репозитории

к примеру у монголибы для шарпика чтоб получить все рекорды нужно писать чето типа collection.Find(x => true).ToList()
я бы с удовольствием написал адаптер для вот этого .Find(x => true) и прозвал его репозиторием, чтобы в коде можно было писать просто GetAll

а collection.ToList()

не варик ?

Это называется LINQ

А вы смишныэ

нет не варик

на коллекции нельзя делать тулист, только через Find

так сделана либа

шо значит LINQ если Find это метод либы))

файнд и в линке есть

Да, но в линке Find возвращает один элемент, а тут видно что в монго Find реализован как Where в linq (чисто судя по вашим комментам)

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

+ лично я не андерстенд как жить с сложными фильтрациями. Возвращать iqueryable - имхо параша, ваще не догоняю смысл такого репозитория, так как даже если мы ограничим нашу абстракцию слоя данных (в плане может быть как бд, так память, так файловое хранилище) до абстракции от конкретной бд (в плане у нас только база данных да), то реализовывать разные провайдеры баз данных могут iqueryable по разному, и поведение может быть разное в итоге на разных провайдерах баз

Лично мне интересно услышать мнение людей которые юзают репозиторий, ибо ну я лично не понимаю как решить проблемы у меня в голове кроме как добавления ещё ко всем патерна спецификации (что бы можно было Expression пилить, что бы оно транслировалось в sql, и что бы можно было спокойно использовать в бизнес логике это). А это уже лютый оверхед для меня. Что бы абстрагироваться от базы которую не дай бог когда то будем писать, усложнять настолько приложение и задерживать каждую фичу ибо пж юзайте все спецификацию паттерн и uof с репозиторием - ну такое

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

За возвращение IQueryable вообще нужно клавой по рукам бить.

Когда возвращается IQueryable и где-то выше вне репозитория что-то фильтруется при необходимости изменить правила фильтрации затр**ешься искать где же умный Вася решил сделать фильтрацию. Аналогично и с методами аля IEnumerable<TEntity> Get(Expression<Func<TEntity, bool>>). Проблемы все те же.

Вообще, ИМХО, репозиторий иногда может быть полезен, т.к. позволяет инкапсулировать логику выбора/получения данных в себе, а наружу отдавать уже готовую коллекцию. Но иногда это ненужный bullshit.

Также многие говорят, что с EF репозиторий не нужен, т. к. DbContext — уже реализует репозиторий и UnitOfWork. Мое мнение, поэтому как раз и нужно сделать свой репозиторий сверху, чтобы снова таки не тягать через всю апку IQueryable

почему не сделаеш 5 строк кода