Каталог решений - #Область ВНЕШНИЕ_ВЫЗОВЫ или MVC в 1С, библиотечность и упрощение интеграции кода

Вместо предисловия — парочка флешбэков.

1. Однажды мне нужно было перенести часть более-менее типовой конфигурации заказчика на самописную конфигурацию. И всё бы ничего, но из кода во все стороны торчали "оборванные провода", вроде:

ОбщегоНазначенияКлиентСервер.СообщитьПользователю

и

ОбщегоНазначения.ЗначениеРеквизитаОбъекта

и ещё десятками других вызовов. Обидно было то, что тянулось это всё в целую кучу модулей, и при этом из каждого модуля использовалась одна-две функции. Переносить все эти модули — значит тащить целую кучу ненужных функций да ещё и цеплять другие модули, которые будут вызываться из этих первых. Переносить только эти функции — да, можно, но, во-первых, большинство из них уже были реализованы в каком-то виде в конфигурации-приёмнике, во-вторых, самое "приятное" было в том, чтобы ходить по коду и выискивать их вызовы. Кто-то скажет, что выискивать можно по сообщениям ошибок. И тут мы перейдём ко второму флешбэку.

2. Когда понадобилось портировать нашу разработку "Все службы доставки в Вашей 1С без изменения конфигурации" с УТ 11.2 на УТ 11.1, оказалось, что есть функции, которые в обеих конфигурациях одинаковые, но по сути разные. Например:

УправлениеКонтактнойИнформациейКлиент.ОткрытьФормуКонтактнойИнформации

в 11.1 принимает 5 параметров, а в 11.2 — три, при этом почти все они необязательные, т.е. на несоответствие количества параметров, если их три в вызове, ошибки не будет, но работать тоже не будет.

3. А ещё бывает так, что функция в УТ 11.1 называется ПОЧТИ также, как в УТ 11.2. Получаешь ошибку, переносишь функцию из одной конфигурации, а там уже есть такая же, только называется на четыре буквы короче.

4. Но самый 1С-стайл — это функции, которые называются одинаково, а действуют по-разному! Например:

УправлениеКонтактнойИнформацией.ПроверитьАдрес

Пока через неделю использования в голову не начнёт закрадываться подозрение, что что-то работает не так, ты туда не полезешь, а искусственный интеллект наших компьютеров ещё не умеет расшифровывать псевдонатуральный интеллект некоторых живых людей.

MVC — WTF?

Что такое MVC лучше расскажет Википедия. В самом общем смысле это идея о том, что Интерфейс не должен знать, что делается в Базе, а Базе должно быть совершенно наплевать, что там в Интерфейсе и вообще интерфейсов может быть много разных или не быть вообще. А общаться База и Интерфейс должны через маленькую дырочку — Контроллер. Зачем это нужно? Чтобы сделать и базу, и интерфейс максимально независимыми, чтобы для изменения базы не нужно было менять все интерфейсы, а при изменении интерфейсов не нужно было трогать базу.

Несмотря на то, что многие программисты в 1С пришли из других языков, где о такой штуке знают, в среде 1С-программирования она не распространена вообще никак. Из нажатия кнопки или обработчика событий элемента формы грязные пальцы вызовы лезут прямо в базу и бизнес-логику, а для изменения реквизитов базы иногда проще переписать конфигурацию с нуля.

Некоторые робкие потуги разделить Логику и Представление уже есть в типовых конфигурациях. Но образцов для подражания там ещё очень немного. Библиотеки, которые прочно вошли в жизнь других языков программирования, начали появляться и в 1С. В основном это — БСП. И там как раз очень не хватает… "библиотечности", возможности безболезненно взять какую-то область (механизм), безболезненно вынуть и вставить в другую среду, без вычищения "торчащих проводов".

На самом деле MVC я здесь задел "по касательной", как одно из воплощений идеи о том, что для упрощения поддержки и интеграции внешнее взаимодействие лучше вынести в ту самую прослойку — Контроллер.

Обратно в 1С

Вдоволь намучившись, в один прекрасный день я выпрыгнул в окно вынес все вызовы внешних модулей в отдельные функции в отдельной области модуля. Примерно так:

#Область ОбщийКод

Процедура ЧёНибудьСделать(КакиеТоПараметры)
    
    Реквизит = Внешний_ЗначениеРеквизитаОбъекта(НашаСсылка, "НашРеквизит");
    Внешний_СообщитьПользователю("Вот такой реквизит: " + Реквизит);
    
КонецФункции

#КонецОбласти


#Область ВнешниеВызовы

Процедура Внешний_СообщитьПользователю(Текст)
    
    ОбщегоНазначенияКлиентСервер.СообщитьПользователю(Текст);
    
КонецПроцедуры

Функция Внешний_ЗначениеРеквизитаОбъекта(Ссылка, Реквизит)
    
    Возврат ОбщегоНазначения.ЗначениеРеквизитаОбъекта(Ссылка, Реквизит);
    
КонецФункции

#КонецОбласти

Что получилось?

• В любой момент времени известно, сколько и какие есть из этого модуля внешние вызовы. При переносе такого модуля ещё до первого теста можно провести 90% работ по интеграции, проверить все вызовы на их соответствия ожиданиям, переопределить то, что изменилось, проверить те самые функции, которые одинаково называются, но действуют по-разному и прочие подводные камни.
• При любых ошибках во время интеграции можно прежде всего смотреть на небольшую область кода с внешними вызовами. Ведь внутреннее взаимодействие в коде не поменялось, ошибки, скорее всего, именно на стыках с внешней средой. А все стыки у нас теперь связаны в один пучок, не нужно ходить по всему коду и искать "торчащие провода".
• Зачастую внешние вызовы — это функции общего назначения, вроде сообщений пользователю и прочих. При этом они же зачастую могут меняться. Да и вызываются они обычно из большого количества мест. И здесь тоже всё стало проще — нужно, например, не сообщать пользователю, а писать в журнал регистрации? Или не вместо, а вместе? Пожалуйста — меняем одну функцию и вуаля.
• Простой, красивый, легко читаемый, легко дорабатываемый код. Мухи у нас отдельно от котлет, появляется некое подобие Модели, которая работает сама по себе, и Контроллера, который отвечает за внешнее взаимодействие.

Спасибо за уделённое время, надеюсь, кому-то данная информация поможет в разработке.