я про построение запроса, такие условия как больше, меньше, равно, есть параметр нет… это все равно где то придется анализировать, и очень будет плохо, если подобных запросов по коду будет много и что то придется менять.
На разных машинах, но на одной СУБД, бд, хранилище ( не важно ). Есть одна замечательная вещь, без которой многопользовательская работа ( корректная ) не возможна блокировки. Реализовав бизнес транзакции, а с ними если нужно блокировки, которые позволят предотвратить одновременное внесение изменений, Предоставлять одновременное редактирование одних и тех же данных — сумасшествие.
У linq запросов есть потрясающее свойство — композируемость. Тебе не надо 18 параметров передавать в функции. Ты можешь 18 раз применить функции (комбинаторы), при этом каждая функция будет тривиальной (IQueryable, param) => IQueryable.
именно по этой схеме и работает QueryBuilder о котором я пишу, и нам все равно нужно анализировать каждый из параметров отдельно.
Если же тебе надо будет в каждом вызове передавать 18 параметров, да еще и править каждый раз код при добавлении нового, то ты быстро забьешь на это дело и будешь просто тянуть всю простыню данных на клиент, а потом фильтровать уже объекты. И под любой серьезной нагрузкой это ляжет.
Вы не знаете о чем говорите. Когда у вас данные вводятся пользователям, то проверить статически почти невозможно.
вариантов может быть много, согласен что не все они могут сразу быть проверены, но те которые могут, лучше всего проверять не отходя далеко, в момент подтверждения действий пользователя
простой, по проекту в 25 местах делаются общие выборки по каким либо критериям, настал момент и уже те же самые запросы должны осуществляться с еще парой параметров. и что? лезть по всему проекту искать где и кто делает такие выборки? Запросы должны быт четко сформулированы в терминах предметной области
связь реализации построителя с параметром запроса.
Для этого достаточно — всего лишь — убрать контекст за интерфейс. Не создать новую прослойку, а просто выделить интерфейс с нужными методами.
сделаем Create Save Delete Query и получим тот же репозиторий.
Чем больше вы прячете, тем меньше возможностей вы оставляете пользовательскому коду, тем беднее он становится (если, конечно, вы не тратите неимоверные ресуры на написание полного DSL).
Меньше возможностей пользовательскому коду — меньше ошибок, да это может доставить некоторые неудобства, но не зря появляется куча DSL, например XAML.
Я предпочитаю взять 18 критериев фильтрации, пришедших с клиента в виде одного AST, сконвертировать их в другой AST и скормить в DAL. Просто и прямолинейно.
да все этого хотят, но на практике приходиться плясать, и не только с бубном, что бы желания вписывались в реалии.
Так в каком же конкретно месте происходит выбор специфичного для конкретной БД способа пейджинга? Если в QueryBuilder, то, удивительным образом, репозиторий для этого не нужен.
Нужен, конфигурация билдера происходит в нем, да это можно сделать и в других местах, репозиторий — фасад, скрывающий создание/удаление/запросы/маппинг и конкретную технологию доступа к данным. Я считаю что очень важно запрещать прямой доступ к контексту данных, тк мы получим описанные здесь проблемы.
предметной областью, то что в предметке есть такой документ, ничего не говорит о том как можно с ним взаимодействовать, исходя из описания поиск можно вести по любому из полей, а почему нет?
Доступно все, что описано в предметной области, это ограждает от невалидных и неэффективных запросов, дублирования и головной боли по совместимости при нескольких бд.
кто ж спорит.