С тем, что объект Запрос в 1С выполняет свои функции, спорить сложно. Но одинаково ли хорошо он подходит для всех случаев? Достаточно ли он лаконичен в "простых" случаях? Достаточно ли нагляден в "сложных" случаях? При попытке подойти к объекту Запрос с позиции методологии разработки возникают следующие вопросы:
- Сам язык запросов и его рекомендуемый стиль слишком громоздкий для "простых случаев". Если наплевать на рекомендуемое оформление, то запрос можно упростить до чего-то вроде "Запрос = Новый Запрос("Выбрать Ссылка Из Справочник.Номенклатура Где ВидНоменклатуры = &МойВид")", что вместе с добавлением параметра и получением результата уложится в три строки, но, на секундочку, в рекомендуемом оформлении - это 10 (десять, Карл!) строк кода.
- Нет запросов на изменение данных. Что мешало сделать простое и удобное платформенное средство непонятно: поверх платформы запросы на изменение сделать можно, значит и в слое платформы тоже было можно.
- Обвязка языка (установка параметров, работа с результатом) хоть и хорошо вписываются в стиль процедурного языка 1С, но также заставляют писать много лишних букв. Для "Запрос.УстановитьПараметр(" уже можно отдельную кнопку на клавиатуре делать
- Текст запроса имеет совершенно отвратительный вид: нет подсветки синтаксиса, необходимость в избыточном оформлении (символ | в каждой строке) делают его сложным для восприятия. Да, подсветку синтаксиса можно получить в конструкторе, но это дополнительно усложняет чтение кода, а на очистку комментариев в этом случае не матерился только ленивый.
- В "сложных" случаях длинный запрос затрудняет чтение процедурного модуля (привет ЗУПу). Частично это решают выносом текста запроса в отдельную процедуру. Так делать начали в типовых, что можно считать официальным признанием наличия проблемы.
Таким образом, можно говорить о том, что реализация запросов в 1С в целом оставляет желать лучшего, а в простых случаях, когда смысл можно было уместить в одну строку, вообще превращает код в длинное и не очень содержательное спагетти. У меня черт возьми, ощущение такое, как будто взяли 20% функционала SQL, прикинули как с помощью этого написать средненький по сложности запрос и на этом успокоились.
При этом "простые" случаи являются наиболее востребованными. Например, в типовой УТ слово ВЫБРАТЬ встречается 22 тысячи раз, а слово СОЕДИНЕНИЕ 11 тысяч раз. Если еще учесть 5 тысяч слов ПОМЕСТИТЬ и тот факт, что соединений в одном запросе бывает несколько - можно говорить, что примерно половина всех запросов являются запросами к одной таблице, т.е. теми самыми "простыми случаями". Это все конечно очень прикидочно.
Т.е. половина запросов написана с использованием инструмента, не лучшим образом подходящего для их написания. Казалось бы, в платформе есть инструмены для получения данных из базы в обход объекта Запрос, такие как НайтиПоРеквизиту, но их использование - это издевательство! Упомянутая НайтиПоРеквизиту ищет только по точному совпадению и только по одному реквизиту и то не по каждому. В типовой УТ, на весь миллион строк кода этот вызов встречается 41 раз, что можно приравнять к признанию бесполезности этого метода. Чтение набора записей регистра сведений по отбору, наверно, самый "юзабельный" инструмент получения данных из базы в обход запросов, но и в нем приходится повторять по пять раз Набор.Отбор....Установить, что не лучшим образом сказывается на читаемости и лаконичности.
Ну правда, что мешало хотябы в метод НайтиПоРеквизитам и принимать на вход структуру? Только не надо про поиск в обход индексов: если будет надо - все равно напишут запрос и будут искать в обход индексов. Займет это вместо одной строки 15, но напишут.
Чтобы окончательно проникнуться идеей ограниченности языка запросов для простых случаев - давайте попробуем глянуть на процедуру, получающую организацию по умолчанию (это не я придумал, это код типовой УТ):
Организация = Справочники.Организации.ПустаяСсылка();
Запрос = Новый Запрос();
Запрос.Текст = "
|ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 2
| Организации.Ссылка КАК Организация
|ИЗ
| Справочник.Организации КАК Организации
|ГДЕ
| НЕ Организации.ПометкаУдаления
| И НЕ Организации.Предопределенный";
Запрос.УстановитьПараметр("ИНН", МойИНН);
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() И Выборка.Количество() = 1 Тогда
Организация = Вборка.Организация();
КонецЕсли;
Возврат Организация;
Делов тут на 3 копейки, а кода 16 строк. Препишем эту функцию на русском языке:
Найти первые две не помеченных на удаление, не предопределенных организации. Если нашлась одна - вернуть ее ссылку, иначе вернуть пустую ссылку.
В этом определении нет упущенной логики, непонятных обобщений и прочих хитростей. Тот факт, что на языке простой логики функция получается в трое короче (263 символа против 900) явно свидетельствует, что выбранный для нее инструмент мягко говоря не совсем подходит. А еще можете взглянуть на мрак в Справочники.Организации.ПолучитьРеквизитыОрганизации... Так совсем не годится.
Вообще, чем меньше в том что вы пишете бизнес-логики и больше каких-то языковых условностей, без которых "не обойтись" - тем менее "плотным", лаконичным будет код, тем больше он будет похож на спагетти, тем хуже он будет читаться и дебажиться.
В 1С явно нужен инструмент, позволяющий получить доступ к данным более лаконичным образом чем язык запросов. Естественно, при этом придется поступиться широкоуниверсальностью, но не настолько чтобы получить что-то бесполезное типа НайтиПоРеквизиту. Хорошо бы получить что-то типа такого:
Организация = Справочники.Организации.НайтиПо("НЕ ПометкаУдаления").ИПо("НЕ Предопределенный").ПолучитьСсылку(Истина);
или типа такого:
Организация = Найти.В("Справочник.Организации").По_("НЕ ПометкаУдаления").ИПо("НЕ Предопределенный").ПолучитьСсылку(Истина);
Как вы пониматете, ничего невозможного в этом нет, а разница между первым и вторым только в наличии функции НайтиПо в модуле менеджера, которая делает вызов Найти.В...
Итак, чтобы не писать каждый раз портянку одинаковых букв, план такой:
1. Делаем общий модуль Найти
2. Пишем в нем обёртку над языком запросов, что-то весьма функциональное, но с простым лаконичным АПИ.
3. Встраиваем вызов процедуры в каждый (или в нужные или только в те, что сняты с поддержки) модуль менеджера.
4. ...
5. PROFIT!
Писать такое не долго, весь мой модуль занимает 250 строк. Делать ли вызов процедур "в одну строку" или нет - вопрос дискуссионный, как делать написано тут.
Некоторые сухие подробности реализации:
- Функция НайтиПо(Параметры...) - функция модуля менеджера, объединяющая указание таблицы и первый фильтр
- Функция задания имени таблицы: В(Имя); Имя - указывается имя таблицы. При встраивании в модуль менеджера пишется один раз или, если встраивание невозможно или нежелательно - каждый раз.
- Функции фильтрации: По_() ИПо() ИНе() ИлиПо() ИлиНе() - функции добавления параметров с соответствующей булевой операцией. В параметрах указывается: имя фильтруемого поля (или само выражение его фильтрации, как в примере "дата между") и, при необходимости, параметры фильтрации. Здесь необходимо пояснить, что для достижения максимальной гибкости и естественной простоты функции пришлось сделать три случая ее функционирования:
- без параметров, для обработки случаев типа И("НЕ ПометкаУдаления")
- с одним параметром, для простого добавления простого равенства, например: И("ВидНоменклатуры", МойВид)
- со сложной обработкой параметров, например: И("Дата МЕЖДУ &Дата1 и &Дата2", ДатаНачала, ДатаКонца). В таком варианте можно задать до трех параметров, а их использование в явном виде указывается. Параметры подставляются по порядку, т.е. в данном случае ДатаНачала будет сопоставлена &Дата1, а ДатаКонца - &Дата2".
- Если использована функция отрицания: ИНе() или ИлиНе()- вся добавленная фраза будет завернута в "НЕ (...)"
- Функции получения результата:
- ПолучитьТаблицу() - эквивалентно "ВЫБРАТЬ * " в запросе и "Запрос.Выполнить().Выгрузить()" в обработке результата
- ПолучитьСсылки() - эквивалентно "ВЫБРАТЬ ССЫЛКА" в запросе и "Запрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Ссылка")" в обработке результата
- ПолучитьСсылку(ТолькоУникальную) - возвращает первую попавшуюся ссылку, соответствующую указанным критериям. Если не найдется - будет возвращено Неопределено. Параметр ТолькоУникальную не обязательный, по умолчанию Ложь, если установлен в Истина - ссылка будет возвращена только если нашлась одна ссылка по указанным критериям, если найдется две - будет возвращено неопределено.
- ПолучитьСсылкуИлиЗначение(ЗначениеПоУмолчанию) - тоже что предыдущее, но если не найдется - будет возвращено ЗначениеПоУмолчанию
- ПолучитьСсылкуИлиИсключение(ТекстИсключения) - тоже что предыдущее, но если не найдется будет вызвано исключение
- ПолучитьПараметры(СписокПараметров) - эквивалентно "ВЫБРАТЬ *" в запросе и помещению первой строки результата запроса в структуру, где ключ соответствует имени колонки, а значение - значению этой колонки в первой строке (если строк не будет - Неопределено) СписокПараметров необязательный, если не задан - в структуре будут заполнены все реквизиты, если задан - в структуре будут присутствовать только указанные реквизиты.
- Пара примеров:
- Документ.ПоступлениеТоваровУслуг.НайтиПо("Номер", Номер).И("Дата Между &Дата1 И &Дата2", Дата1, Дата2).ИНе("ПометкаУдаления").ПолучитьТаблицу();
- Справочник.Номенклатура.НайтиПо("ВидНоменклатуры В (&Виды)", МассивВидов).ИЛИ("СтавкаНДС", Перечисления.СтавкиНДС.НДС0).ПолучитьСсылки();
Платформа 8.3.9.2233, код открыт, даунгрейд возможен при реализации функций типа СтрНачинаетсяС.
Удачи!
