fkthatВот, типичный пример кода, наподобии того, который у нас в репах:




Ну так тут нет и даже не пахнет никакими отложенными вычислениями.
Почему бы тогда не вернуть IReadOnlyCollection, например?

А если хочется отложенных запросов и полного вагона преимуществ, почему не вернуть IQueryable?

Какое-то упорное жевание кактуса. Как много я такого в чужих проектах видел, люди вы так любите боль? :))

fkthatПроблема в инкапсуляции. Сегодня внутри репо список, а завтра окажется HashSet.

Эмм.. IQueryable -- отличная инкапсуляция в рамках ORM.

Если хотите инкапсулироваться по самые помидоры, чтоб всё-всё можно было заменить (мы каждую неделю меняем СУБД, ОРМ-ы и даже языки программирования и платформы, в живых проектах), тогда тут репо, боюсь, не выстоит под напором требований. В CQRS уходить нужно, или как минимум в Query Object.

Но IEnumerable тут вообще не решает задачу, так как никакими отложенными вычислениями тут не пахнет. Извините, но нет. А вот проблем создаёт. Тупо, количество приходится считать переходом, до идиотизма уже.

fkthatПотому что не везде тот же сиквел, и не везде даже EF. Поэтому не любой IQueryable будет поддерживать любой LINQ запрос. И каждый раз гадать - выполнится он или кинет "unsupported" иксепшен никто не хочет. Говорили же выше - слой репо - это слой абстракции над хранилищами, а не просто ничего не делающая по сути обертка над DbContext.

Если используете ORM в виде EF, значит архитектуру работы с данными строите поверх него, там вся суть не только в LINQ, но и целый обвес.

Вообще, решать задачу будущей замены ORM/EF/СУБД -- это удел джунов. Без обид, я сам таким болел когда-то. Это никому не нужная, бесполезная, настолько же беспощадная как и бессмысленная задача. Никто никогда не меняет ни ORM, ни СУБД на живых проектах. А даже если и приходится менять, то никакого волшебства никогда не получится, даже если в лоб расшибиться на абстракциях.

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

Это значит, что рано или поздно вам понадобится: кеширование, метрика, безопасность, масштабирование, блокировки, распределение по различным хранилищам и т.д.

И дело вовсе не в "exception", которого вы так боитесь от LINQ запроса. EF такие проекты вывозит, вам и не снилось. Поэтому если занимаетесь глупостями с возвратом IEnumerable вместо IQueryable, то конечно ваше дело, рано или поздно поймёте, что фигнёй страдали :)

fkthat,

В ином случае, репо для целей полной абстракции от хранилища работает очень плохо. Прям очень.

stenfordты писал, что это "перечисление, которое может быть или бесконечным генератором, или иметь свойство одноразового применения и за его использование убивать надо". Вроде ничего из твоего бредогенератора не упустил. Дошло наконец, что не будет у репозитория никаких проблем со множественным перечислением IEnumerable? Гуд, одну шизу вылечили. А IQueryable вообще здесь из другой оперы, показывает только, что ты ничего кроме своего магазина с губной помадой не делал размазывая код запросов по всей системе

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


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

У вас какой-то болезненный пунктик про помадные магазинчики, это пока всё что понятно из ваших комментариев.


stenfordнет никакого криминала вернуть и IReadOnlyCollection, но IEnumerable более общий и вполне достаточный для большинства операций

Вроде уже все сказал по этому поводу, эти интерфейсы не просто так добавили. А если бы вы изволили потрудиться, то нагуглили бы материалы по этой теме. А был бы опыт разработки чего-то большего чем, как вы там сказали, "помадных магазинчиков", тогда бы вас волновали вопросы производительности, правильной семантики и надёжности кода. Но видимо это не про вас.