stenfordя спросил, дошло-ли до тебя что проблем с множественным перечислением у IEnumerable за которые ты собирался убивать у репозиториев не будет? Или переформулировать этот вопрос в еще более простой форме?

Я уже привёл список проблем, связанных с IEnumerable. Зачем вы просите меня повторяться? Если с чем не согласны, напишите. Если непонятно, перечитайте.

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

Я не призывал что-то делать автоматически и не думая, да аргументов я до сих пор не вижу кроме того, что вы считаете IEnumerable адекватным интерфейсом. Жаль вы до сих пор не можете пояснить почему.

fkthatРаботает очень хорошо. Ты, походу, никак не понимаешь, что наружу там не торчит никакого ни LINQ ни EF, ничего подобного. Мы возвращаем только уже готовые объекты или коллекции объектов, выбранные по некоторым нужным нам критериям. Что там при этом внутри все это скрыто. Есть скажем интерфейс:



У сиквельного репо реализации Find и Get будут одни, у монговского другие и т.п. А снаружи это без разницы и с т.ч. клиента выглядит одинаково.

Я всё равно не вижу, почему не вернуть интерфейс коллекции, если никаких отложенных вычислений нет, и вы возвращаете ни что иное, как коллекции. И по семантике, и по факту.

Но вторая проблема здесь заключается в том, что такое у вас Foo? Это агрегат, сущность? Есть ли возможность получить корень агрегата полностью? Или такое поведение у вас инкапсулируется в объекте Query?

Что делать с пейджингом? Приведённый вами интерфейс в упор этого не поддерживает, даже при всём желании.

fkthatУ сиквельного репо реализации Find и Get будут одни, у монговского другие и т.п. А снаружи это без разницы и с т.ч. клиента выглядит одинаково.

Это безусловно хорошо. Таким и должен быть репозиторий.


fkthatА в твоем ошибочном представлении репо это что-то такое:



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

А с чего вы решили, что я буду тупо свойство контекста возвращать? И с чего вы решили, что IQueryable не может ходить через EF, Mongo и т.д. и т.п.? Эта та же абстракция, что и ваш Query.

fkthatСразу вопрос. Какой именно коллекции? Мне нравится Array, Васе нравится List, а Вове, так вообще HashSet.

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

IReadOnlyCollection появился в библитеке, к сожалению, слишком поздно. К тому времени многие привыкли к IEnumerable, наплевав на семантику, производительность, эффективность и сопровождение.

Почему всегда в спорах в инженерной дисциплине часто скатываются к фломастерам? Что за странная тенденция такая, нездоровая.


fkthatПотом, мне например, удобно внутри репо работать с массивом, я вот беру и возвращаю массив. А потом алгоритм поменялся, и стало удобно возвращать List. Что мне делать?

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


fkthatГородить костыли внутри репо, или ломать все что снаружи? Это другая сторона инкапсуляции - не тольько спрятать что должно быть спрятано, но и иметь возможность это спрятанное поменять, не затрагивая ничего внешнего.

Интерфейс коллекции вашим требованиям удовлетворяет.

fkthat,

Продолжим. Про пейджинг вы мне не ответили. Как оказалось, отложенные асинхронный вычисления ваши репо не поддерживают.

А что делать, если вам нужна проекция? Или огромное число проекций? Или проекции, которые на стадии разработки неизвестны? Будете периодически лазить и допиливать репо? Ох, как же это бьёт в ущерб идеи полной независимости и инкапсуляции.

IQueryable отвечает задачам и асинхронного отложенного вычисления, и возможности пейджинга, и возможности бесчисленных эффективных проекций без изменения ни строчки кода репо. На нём можно реализовать OData, например. Или кастомный протокол, выбирающий требуемые данные (конкретные поля), не вытягивая остальное. Возможность тянуть данные по связям, дааа, и фильтровать по ним. Даже фильтровать по агрегациям.

Я не к тому, что IQueryable интерфейс это лучший способ работы с данными на все времена. Не всегда он подходит. Я делал проекты на IQueryable, большие и на CQRS и c EventSourcing, и даже было дело на ActiveObject.

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

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

Реальные задачи его не интересуют :)
Сам такой был, сам таким отчасти остаюсь...

fkthatВозвращай что хочешь. С такими упоротыми как ты работать только один способ - во всем с ними соглашаться, и наблюдать как они сами себе могилу роют. Тем более если оценить, то, пожалуй, я за свою жизнь процентов 80 денег из заработанных мной в айти заработал за ковыряние в чужом говнокоде, т.ч. чем вас больше, тем мне лучше

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

ЕвгенийВНе учи людей плохому. Он декларирует только то. что посредством него, ты ничего не сможешь добавить.

Верно, что и означает read only,


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

Так полагать можно про всё что угодно, и даже про "неизменяемые" строки. Контракт означает, что он ДОЛЖЕН соблюдаться, и что этого МОЖНО ожидать. Но если как ты говоришь, не верить контракту, то далеко ты не продвинешься, по-больше try/catch, фреймворку тоже доверять нельзя. Откуда ты знаешь, что вместо открытого дескриптора файла тебе не вернут просто какое-то рандомное число? Никогда не знаешь.

Бред в общем, аргумент странный.