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