Что вы имеете ввиду под репозиторий торчит наружу? У репозитория есть чёткая цель и места где он может размещаться по проекту и конечно его интерфейс должен "торчать" для клиентского кода.
То что репозиторий перестаёт быть генерик это что значит? На сколько я понял генерик это именно реализация c# который в себе содержит методы crud, ну допустим у вас не генерик репозиторий, а обычный с кучей операций
Mongo считает сам, в один проход на стороне БД - ни сама база, ни драйвер к ней тут ничего "не умеют". Я не приписываю репозиторию сложность запроса, а показываю обратное: контракт generic-репозитория не даёт воспользоваться тем, что база уже умеет.
Тут вы вообще последовательность теряете, то у вас это делает монго, в середине никто ничего "не умеет", а в конце опять монго все делает(
Ну я если честно не знаю зачем себя ограничивать генерик репозиторем, когда можно пользоваться обычным))
А маппинг есть в с#? Нельзя написать датамапер который IQueryable завернет в какую-то структуру которая будет вам удобнее?) Тем самым и абстракция от EF добавится :)
Как я вижу - вы всю статью прикрывает свои же ошибки, и ищите их везде кроме своих решений))
1 В статье вся боль начинается с того что для бизнес аналитики одна база представляет простой механизм, а во второй надо разбираться самому и писать запрос (обратите внимание что здесь эта проблема приписывается репозиторию!!!) Хотя возможно тут проблема что ОРМ через которую пишутся запросы не предоставляет возможности на такой запрос)
2 По поводу возврашаемых данных через репозиторий - там может быть любой тип, если вы в репозитории просто отправляете ответ ОРМ, то не надо сетовать на то что репозиторий возвращает IQueryable
По итогу получился какой-то ком грязи (чисто моё мнение по прочитаному из статьи) где вместо решения проблем , которые на прямую к репозиторию не относятся, предлагается разделять запросы по принципу CQRS, мотивируя это тем что по другому думать надо как аналитику писать))
Прекрасная иллюстрация как проблема привалирует над архитектурой)
попробовать две UI-библиотеки за день, чтобы выбрать ту, которая нравится больше, больше не требует долгого изучения их документации
Сэкономили целый час на своём развитии.
Скорее бы все агентам делегировать, да сидеть деградировать)
А когда все сдеградируют, тогда цены на ИИ взлетят как на монополию знаний)
К этому, как мне кажется, они ведут массовое сознание)
Но с другой стороны нейронка ничего не может выдать вперёд человека, сначала человек учит нейронку, только после этого она что-то умеет. Получается что разработчики нужны ИИ компаниям чтобы обучать нейронку на их коде.
Какой-то замкнутый круг получается, но самое главное что бабосы мутятся, а это главный показатель эффективности)
А такой подход что менеджеры сначала продают то чего нету (красивые сказки про новый функционал) чтобы получить премию и закрыть kpi, а разработчики дальше сами разберутся и впихнут невпихуемое, не смущает вас?)
Да понятно, недавно же кто-то из ИИ мейнстримеров говорил что ии ориентировано на код потому что там водятся деньги) не потому что она хорошо его пишет, прошу заметить))
Мне кажется это частая ошибка в понимании репозитория.
Если у вас данные абстрагированны репозиторием, это не значит что вы можете просто в проекте переключать источники данных как захотите.
При необходимости сменить или добавить источник данных - пишем новую реализацю репозитория, подставляем в алиас новый репозиторий и все)
По моему очень элегантно и удобно)
Ну и по реализации репозиторий явно не самый сложный паттерн)) Но один из самых важных, как по мне
Что вы имеете ввиду под репозиторий торчит наружу? У репозитория есть чёткая цель и места где он может размещаться по проекту и конечно его интерфейс должен "торчать" для клиентского кода.
То что репозиторий перестаёт быть генерик это что значит? На сколько я понял генерик это именно реализация c# который в себе содержит методы crud, ну допустим у вас не генерик репозиторий, а обычный с кучей операций
Тут вы вообще последовательность теряете, то у вас это делает монго, в середине никто ничего "не умеет", а в конце опять монго все делает(
Ну я если честно не знаю зачем себя ограничивать генерик репозиторем, когда можно пользоваться обычным))
А маппинг есть в с#? Нельзя написать датамапер который IQueryable завернет в какую-то структуру которая будет вам удобнее?) Тем самым и абстракция от EF добавится :)
Под конец статьи все собралось в картину.
Как я вижу - вы всю статью прикрывает свои же ошибки, и ищите их везде кроме своих решений))
1 В статье вся боль начинается с того что для бизнес аналитики одна база представляет простой механизм, а во второй надо разбираться самому и писать запрос (обратите внимание что здесь эта проблема приписывается репозиторию!!!) Хотя возможно тут проблема что ОРМ через которую пишутся запросы не предоставляет возможности на такой запрос)
2 По поводу возврашаемых данных через репозиторий - там может быть любой тип, если вы в репозитории просто отправляете ответ ОРМ, то не надо сетовать на то что репозиторий возвращает IQueryable
По итогу получился какой-то ком грязи (чисто моё мнение по прочитаному из статьи) где вместо решения проблем , которые на прямую к репозиторию не относятся, предлагается разделять запросы по принципу CQRS, мотивируя это тем что по другому думать надо как аналитику писать))
Прекрасная иллюстрация как проблема привалирует над архитектурой)
Сэкономили целый час на своём развитии.
Скорее бы все агентам делегировать, да сидеть деградировать)
А когда все сдеградируют, тогда цены на ИИ взлетят как на монополию знаний)
К этому, как мне кажется, они ведут массовое сознание)
Но с другой стороны нейронка ничего не может выдать вперёд человека, сначала человек учит нейронку, только после этого она что-то умеет. Получается что разработчики нужны ИИ компаниям чтобы обучать нейронку на их коде.
Какой-то замкнутый круг получается, но самое главное что бабосы мутятся, а это главный показатель эффективности)
Интересно какая из категорий каждый день пишет статьи про ИИ на Хабре...
Ну и чушь, а когда я увидел что у вас "свободная" архитектура производительнее чем чистая, то даже читать перестал)
Мечты менеджеров и причастных о горе денег за их умение продать разбиваются об реальность))
В каком месте это то же самое когда одно причина, а другое следствие)
Проблема в том что если человек не был разработчиком достаточно времени, то он становится не менеджером продукта, а продавцом воздуха.
Ну и в статье у вас про это не слова, вы это называете "вежливостью" вместо честного - не быть уволенным за правду)) Даже тут какая-то подмена понятий
Согласен, везде где я работал инициатива была наказуема...
Причём работал в совершенно разных компаниях, но болячки одни и те-же...
А такой подход что менеджеры сначала продают то чего нету (красивые сказки про новый функционал) чтобы получить премию и закрыть kpi, а разработчики дальше сами разберутся и впихнут невпихуемое, не смущает вас?)
Вы хотели сказать знание?
Знание и должность часто идёт параллельно в сегодняшних реалиях)
Люди, наверное, хотят снизить когнитивную нагрузку потому что думать тяжело, давайте признаем что не каждому заставлять себя думать посильная задача)
Да понятно, недавно же кто-то из ИИ мейнстримеров говорил что ии ориентировано на код потому что там водятся деньги) не потому что она хорошо его пишет, прошу заметить))
Ну раньше говорили к концу года иишечка начнет за всех код писать, теперь 2-4 года)) потом 5-10 лет
Вы же здесь говорите именно про себя.
Для тех, кто поддерживает код на ассемблере, читаемость кода также важна как и на любом языке))
Точно современный программист, паттерны нужны только чтобы собеседование пройти, классика))
Это безусловно. Мне просто показалось что автор так не думает и бизнес у него где-то отдельно существует)
Под рынком наверное имеется ввиду бизнес, а не потребитель))
Тогда все сходится, бизнесу главное продать, хоть кусок г... в вайбкод обёртке))
Качественная архитектура тоже, но её не рекламируют везде, наверное поэтому её почти нигде нету, а иишечка есть?)
Ну или просто так боится за прибыль что ведётся на рекламные лозунги ;)