кстате а как ваш класс будет справляться с 18 параметрами, которые где то тут гуляют. Передадим это в функцию? (о да класс) а она передаст это в query? замечательно
Лучше — сделать проекцию, но вы не можете так сделать, потому что хотите тянуть целые объекты. Все остальное быстродействию не поможет. Самый лучший запрос можно составить точно зная как его результаты будут обрабатываться. Увы ваш репозиторий лишает такой возможности.
я привел самый простой случай, ни кто не мешает передать в билдер context и там вывернуть его на изнанку.
То есть запросов получится много даже для такой примитивнй модели. Что уж говорить о сложных моделях…
да ладно, можно группировать запросы, например запрос зака, передовать с запросом пользователя в репозитория пользователей, обернуть билдеры в фабрику, а в нутри репозитория можно это все дело совместить и скомбинировать, сделать проекции и тд, не проблема
EF запросы не строит, их строит программист
вот именно, это на его совести, к сожалению совесть вещь не предсказуемая.
Прости, но никто не умеет. Если у тебя в модели DateTimeOffset, то половина провайдеров тебя пошлют нафиг. Если у тебя нет DateTimeOffset в модели, то все провайдеры для EF спокойно прожуют твою модель. Лишние прослойки тут не помогут.
речь не только о типах, но и о самих провайдерах, как они отработают на одних и тех же запросах заранее сказат ьне возможно
context.Where(e=>e.Value == true). простой пример, я в коде на прямую обратился к контексту, сменил провайдер и запрос неэффективен, как мне выйти из этой ситуации с гарантией, что никто никогда это не сможет повторить.
как раз наоборот, если для предметной области нужен поиск по строке, то лучше всего подойдет хранить тела документов в файлах, отфильтровать документы из бд, получить расположение файлов, провести поиск в них, эт овсе можно скрыть все тем же репозиторием
действительно классный пример, я бы ввел блокировку, признак того что билет на данное место продается, но еще не подтвержден, тогда и не получиться проблем. Кстати не сложно.
Причем копипаста в итоге будет как в самом классе query, так и в QueryBuilder.
о каком копипасте идет речь в билдере?
Но чтобы работало быстро — надо иметь много запросов, под каждый сценарий нужен свой специализированный запрос.
поэтому и описние идет в терминах предметной области, а там где запрос выполняется идет анализ как лучше обработать данный запрос.
У меня примитивное приложение с 5 таблицами генерирует 150 разных запросов.
на сколько элементарных подзапросов можно их разбить? или они все уникальны?
Берем простой интернет-магазин. Товары-Клиенты-Заказы-Позиции. 4 сущности всего.
Функции: каталог товаров, создание заказа, список заказов для менеджера,
а для магеров таблички нет? все сущности являются корнями..
То же самое делает EF. То есть вы в репозитории объединили функции построения запросов и исполнения запросов,
умеет ли он строить идентичные запросы которые будут одинаково адекватно выполняться на разных БД — нет. Безопасно ли заменять один провайдер другим — нет. Умеет ли EF адекватно сохранять корни агрегации — нет, умеет ли он правильно сохранять корни — нет.
что нарушает SRP
Secure Remote Password?
да еще и пессимизироали программу
пессимизироали это противоположенное оптимизировали?
А если возникает конкурентный доступ с нескольких серверов к одним и тем же данным?
а вот тут забавная ситуация, сидел пользователь пол часа правил, пытается сохранить, опаньки кто то до него внес изменения и сохранил, и мы рушим его работу, эх
ни кто не мешает, но так же ни кто не мешает их не использовать и легко идти в обход системы.
А какая разница в чем сформулированы запросы, если все равно надо искать и править?
Вот у нас есть User вот у нас запрос в терминах предметной области query.AvaibleUsers, отлично avaible определяется заблокирован пользователь или нет, через какое то время вводиться еще одно свойство Baned, и теперь доступность определяется не заблокирован и не забанен, обратите внимание что запрос как был так и остался, измениось только его исполнение.
Прочитал ваш код, у вас нет проекций, вы всегда тянете полные сущности. Это тормозит.
это простейший пример, для оптимизации используются параметры прогрузки сущностный (аля Include ), так же в терминах предметной области.
Самое интересное, что метод Get у вас принимает один Query, то есть никакой декомпозиции, все параметры запроса надо выписать по месту вызова.
декомпозиция — если не заполнено, значит нет,
У каждой сущности будет постраничная разбивка, у половины фильтры активных, еще у части фильтры доступа.
плохо написано, возможно не разобрал, но для каждого репозитория свой query
То есть у вас в Query должны быть все возможные параметры для всех возможных запросов. На практике нежизнеспособное решение.
правильно определив корни агрегации и хорошо зная предметную область разбив все крупные запросы на простые как правило получается что и вариантов та таких подзапросов на конкретную предметку не много.
Кстати вы применил зачем-то словарь, вместо полиморфизма. Почему Query не может накладывать фильтры на IQueryable сам?
для того что бы решить проблему совместимости, переопределив нужные билдеры запросов
И в итоге все это делалось, чтобы вызвать разные методы Build для разных провайдеров. Только я так и не понял, почему нельзя нужный QueryBuilder заинжектить в БЛ и не использовать репозитории вообще? И проблем с проекциями не будет.
потому что реп это не просто построитель запросов — он умеет создавать сохранять удалять еще и маппинг,
я привел самый простой случай, ни кто не мешает передать в билдер context и там вывернуть его на изнанку.
да ладно, можно группировать запросы, например запрос зака, передовать с запросом пользователя в репозитория пользователей, обернуть билдеры в фабрику, а в нутри репозитория можно это все дело совместить и скомбинировать, сделать проекции и тд, не проблема
вот именно, это на его совести, к сожалению совесть вещь не предсказуемая.
речь не только о типах, но и о самих провайдерах, как они отработают на одних и тех же запросах заранее сказат ьне возможно
а как узнать какой запрос критический если у нас «доступную коду-потребителю функциональность» есть доступ и тут можно пилить что угодно и как угодно.