Цитата:
Сообщение от
Владимир Максимов
Работа с Query - это довольно часто выполняемая операция. Как следствие,
удобнее вынести эту обработку в общую "библиотеку" пользовательских функций Global, о которой "все знают", чем в специализированный класс SysQuery о котором еще надо "вспомнить"

Проблема выноса подобных функций в Global в том, что Global в итоге превращается в помойку, где можно что-то
очень долго искать, и... в конце концов действительно найти. ИМХО, Global - это место для расширения множества функций ядра, таких, как, например, расширения базовых функций работы со строками. Т.е. то, что не привязано к тому или иному специфическому функционалу.
Когда туда начинают сливать все подряд (ну а что, кому-нибудь пригодится же!), Global превращается не пойми во что с кучей непонятного и зачастую дублирующего друг друга функционала.
В итоге каждый раз начинаем искать то что нам подойдет:
Цитата:
Сообщение от
Владимир Максимов
Это уже лично я пишу имя класса, чтобы не вспоминать точное название метода, а посмотреть в выпадающем списке после ввода двоеточий.
Мне кажется намного удобнее, когда вспомогательные функции именно для работы с запросами собраны в одном классе SysQuery, что в итоге значительно сужает область поиска. И другие такие примеры тоже есть, даже среди системных классов, например, DateUtil для utcdatetime или CLRInterop для работы с .NET. А есть еще, например, WinAPI/WinAPIServer
Цитата:
Сообщение от
Владимир Максимов
Ну, и еще появляется возможность внести дополнительные параметры и обработки, не трогая класс SysQuery. Например, добавить второй параметр по аналогии с методом global::queryRangeConcat(), чтобы добавлять отрицание к уже существующему условию.
А почему его нельзя трогать?