При разработке и интеграции расширений для платформы 1С:Предприятие программисты часто сталкиваются с выбором технологии создания внешних компонент (ВК). На текущий момент существует два основных стандарта: COM (Component Object Model) и Native API. Понимание различий между ними критически важно для обеспечения стабильной работы системы на разных операционных системах и в разных режимах работы (клиент, сервер, веб). Разберем по шагам ключевые особенности каждой технологии.
Технология COM является «классическим» способом расширения функционала 1С, который использовался еще со времен версии 7.7. Рассмотрим ее основные характеристики. COM-компонента — это программный объект, созданный по стандартам Microsoft. Взаимодействие платформы 1С с такой компонентой происходит через стандартные интерфейсы Windows (в частности, IDispatch). Платформа обращается к методам компоненты по их числовым идентификаторам (DISPID).
Одной из главных особенностей COM-компонент является необходимость их регистрации в реестре Windows. Для этого обычно используется утилита regsvr32.exe. Проанализируем последствия такого подхода: для регистрации компоненты требуются права администратора, что может быть затруднительно в строгих корпоративных средах. Кроме того, регистрация в реестре «привязывает» компоненту к конкретной машине, что усложняет процесс автоматического обновления и доставки кода пользователям.
Важным преимуществом COM, которое отмечают опытные разработчики, является возможность работы с внутренними объектами 1С непосредственно из кода компоненты через специализированные интерфейсы. Однако стоит помнить, что COM — это сугубо Windows-зависимая технология. Она не будет работать на Linux-серверах, в мобильных приложениях или на macOS.
Native API — это современный стандарт, разработанный фирмой 1С специально для обеспечения кроссплатформенности. Выясним, почему Native-компоненты стали стандартом де-факто в современных конфигурациях. В отличие от COM, Native-компонента не использует системные механизмы регистрации Windows. Платформа 1С загружает библиотеку (DLL для Windows, SO для Linux) напрямую в адресное пространство процесса.
Рассмотрим механизм взаимодействия: платформа запрашивает у компоненты индекс метода по его строковому имени (через функцию FindMethod), а затем вызывает этот метод. Это позволяет легко реализовывать многоязычность, когда один и тот же метод компоненты можно вызвать как на русском, так и на английском языке (например, Подключить() и Connect()).
Главное преимущество Native API — это кроссплатформенность. Одна и та же логика, упакованная в соответствующие файлы под разные ОС, будет успешно работать на:
Проанализируем ситуацию с точки зрения системного администрирования и поддержки. Для использования COM-компоненты нам нужно обеспечить наличие библиотеки на диске и ее регистрацию в реестре. Если мы обновляем версию компоненты, нам нужно перерегистрировать её на всех рабочих местах.
В случае с Native API платформа предлагает механизм AddIn bundle. Это обычный ZIP-архив, содержащий манифест (XML-файл) и наборы библиотек под разные архитектуры (x86, x64) и операционные системы. Разберем алгоритм работы платформы при использовании метода УстановитьВнешнююКомпоненту():
Такой подход делает Native-компоненты идеальными для тиражных решений, так как доставка кода пользователю происходит полностью автоматически средствами 1С.
Выясним причину, по которой Native-компоненты считаются более стабильными. В Native API предусмотрен интерфейс IMemoryManager. Когда компоненте нужно выделить память для передачи данных в 1С (например, возвращаемую строку), она запрашивает эту память у менеджера платформы. Если компонента по какой-то причине завершит работу некорректно, платформа сможет сама очистить выделенные ресурсы.
В COM-компонентах управление памятью (подсчет ссылок AddRef и Release) полностью лежит на разработчике. Ошибки в реализации этих механизмов часто приводят к «утечкам» памяти или падению всего процесса 1С (особенно на стороне сервера), что крайне сложно отлаживать.
Несмотря на явные преимущества Native API, выбор технологии зависит от конкретных задач. Рассмотрим рекомендации по выбору:
Выбирайте COM, если:
Выбирайте Native API, если:
Посмотрим на пример кода, как универсально подключать компоненты в зависимости от их типа. Для Native-компоненты, упакованной в макет, код будет выглядеть следующим образом:
&НаКлиенте
Процедура ПодключитьКомпоненту()
Результат = УстановитьВнешнююКомпоненту("ОбщийМакет.МояКомпонентаNative");
Если Результат Тогда
Подключено = ПодключитьВнешнююКомпоненту("ОбщийМакет.МояКомпонентаNative", "MyComponent", ТипВнешнейКомпоненты.Native);
Если Подключено Тогда
ОбъектВК = Новый("AddIn.MyComponent.Extension");
// Работаем с объектом
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Для COM-компоненты, уже зарегистрированной в системе, вызов будет проще, но менее гибким в плане кроссплатформенности:
&НаКлиенте
Процедура ПодключитьCOM()
Попытка
ОбъектВК = Новый COMОбъект("MyCompany.MyComComponent");
// Работаем с объектом
Исключение
Сообщить("Компонента не зарегистрирована в системе!");
КонецПопытки;
КонецПроцедуры
В заключение отметим, что хотя COM-технология все еще работоспособна и имеет своих сторонников, стратегическим направлением развития платформы 1С является именно Native API. Она обеспечивает безопасность, масштабируемость и независимость от операционной системы, что является критическим фактором для современного бизнеса.