Правила створення спільних модулів

Див. також

1.1. Спільні модулі створюються для реалізації процедур і функцій, об'єднаних за певною ознакою. Як правило, в одному спільному модулі розміщуються процедури і функції однієї підсистеми конфігурації (продажі, закупівлі) або процедури і функції подібного функціонального призначення (робота з рядками, загального призначення).

1.2. Під час розробки спільних модулів слід обирати один із чотирьох контекстів виконання коду:

2.1. Серверні спільні модулі призначені для розміщення серверних процедур і функцій, недоступних для використання з клієнтського коду. У них реалізується вся внутрішня серверна бізнес-логіка застосунку.
Для коректної роботи конфігурації в режимах зовнішнього з'єднання, керованого та звичайного застосунків серверні процедури і функції слід розміщувати у спільних модулях з ознаками:

• Сервер (прапорець Виклик сервера скинуто),
• Клієнт (звичайний застосунок),
• Зовнішнє з'єднання.

У такому разі гарантується можливість виклику серверних процедур і функцій з параметрами мутабельних типів (наприклад, СправочникОбъект, ДокументОбъект тощо). Як правило, це:

• обробники підписок на події документів, довідників тощо, які приймають як параметр мутабельне значення (об'єкт).
• серверні процедури і функції, до яких як параметр передається об'єкт із модулів довідників, документів тощо, а також із модулів із підписками на події.

Серверні спільні модулі називаються за загальними правилами іменування об'єктів метаданих.
Наприклад: РаботаСФайлами, ОбщегоНазначения

В окремих випадках для запобігання конфлікту імен із властивостями глобального контексту може бути додано постфікс «Сервер».
Наприклад: РегламентныеЗаданияСервер, ОбменДаннымиСервер.

2.2. Серверні спільні модулі для виклику з клієнта містять серверні процедури і функції, доступні для використання з клієнтського коду. Вони становлять клієнтський програмний інтерфейс сервера застосунку.
Такі процедури і функції розміщуються у спільних модулях з ознакою:

• Сервер (прапорець Виклик сервера установлено)

Серверні спільні модулі для виклику з клієнта називаються за загальними правилами іменування об'єктів метаданих і повинні іменуватися з постфіксом «ВызовСервера».
Наприклад: РаботаСФайламиВызовСервера

Слід мати на увазі, що експортні процедури і функції в таких спільних модулях не повинні містити параметрів мутабельних типів (СправочникОбъект, ДокументОбъект тощо), оскільки їх передавання з (або до) клієнтського коду неможливе.

Див. також: Обмеження на встановлення ознаки «Виклик сервера» у спільних модулів

2.3. Клієнтські спільні модулі містять клієнтську бізнес-логіку (функціональність, визначену лише для клієнта) і мають ознаки:

• Клієнт (керований застосунок)
• Клієнт (звичайний застосунок)

Винятком є випадки, коли клієнтські процедури і функції мають бути доступні лише в режимі керованого застосунку (лише в режимі звичайного застосунку або лише в режимі зовнішнього з'єднання). У таких випадках допустима інша комбінація цих двох ознак.

Клієнтські спільні модулі іменуються з постфіксом «Клиент».
Наприклад: РаботаСФайламиКлиент, ОбщегоНазначенияКлиент

Див. також: мінімізація коду, що виконується на клієнті

2.4. В окремих випадках допустиме створення клієнт-серверних спільних модулів із процедурами і функціями, вміст яких однаковий і на сервері, і на клієнті. Такі процедури і функції розміщуються у спільних модулях з ознаками:

• Клієнт (керований застосунок)
• Сервер (прапорець Виклик сервера скинуто)
• Клієнт (звичайний застосунок)
• Зовнішнє з'єднання

Спільні модулі цього виду іменуються з постфіксом «КлиентСервер».
Наприклад: РаботаСФайламиКлиент, ОбщегоНазначенияКлиентСервер

У загальному випадку не рекомендується визначати спільні модулі одночасно для сервера і для клієнта (керований застосунок). Функціональність, визначену для клієнта і для сервера, рекомендується реалізовувати в різних спільних модулях – див. пп. 2.1 і 2.3. Такий явний поділ клієнтської та серверної бізнес-логіки зумовлений міркуваннями підвищення модульності прикладного рішення, спрощення контролю з боку розробника за клієнт-серверною взаємодією та зниження ризику помилок через принципові відмінності вимог до розробки клієнтського і серверного коду (необхідність мінімізації коду, що виконується на клієнті, різна доступність об'єктів і типів платформи тощо). При цьому потрібно мати на увазі неминуче збільшення кількості спільних модулів у конфігурації.

Особливим випадком змішаних клієнт-серверних модулів є модулі форм і команд, які спеціально призначені для реалізації серверної та клієнтської бізнес-логіки в одному модулі.

3.1. Імена спільних модулів рекомендується будувати за загальними правилами іменування об'єктів метаданих. Назва спільного модуля має збігатися з назвою підсистеми або окремого механізму, процедури і функції якого він реалізує. Рекомендується уникати в назвах спільних модулів таких загальних слів, як "Процедури", "Функції", "Обробники", "Модуль", "Функціональність" тощо, і застосовувати їх лише у виняткових випадках, коли вони повніше розкривають призначення модуля.

Щоб розрізняти спільні модулі однієї підсистеми, які створені для реалізації процедур і функцій, що виконуються в різних контекстах, рекомендується задавати їм постфікси, описані раніше в пп. 2.1-2.4.

3.2. Додатково до спільних модулів можуть бути додані уточнювальні постфікси.

3.2.1. Для глобальних модулів додається постфікс «Глобальный», у цьому разі постфікс «Клиент» додавати не слід.
Наприклад: РаботаСФайламиГлобальный

3.2.2. Модулі, що виконуються в привілейованому режимі, мають ознаку Привилегированный, іменуються з постфіксом «ПолныеПрава».
Наприклад: РаботаСФайламиПолныеПрава

3.2.3. Модулі, призначені для реалізації на сервері або на клієнті функцій із повторним використанням значень, що повертаються протягом сеансу, іменуються з постфіксом «ПовтИсп» і «КлиентПовтИсп» відповідно.
Наприклад: РаботаСФайламиКлиентПовтИсп

3.2.4. Серверні та клієнтські модулі бібліотечних конфігурацій (які призначені не для самостійного використання, а для розробки інших конфігурацій) із процедурами і функціями, що допускають зміну своєї реалізації, іменуються з постфіксами «Переопределяемый» і «КлиентПереопределяемый».
Наприклад: РаботаСФайламиКлиентПереопределяемый

Див. також: Перевизначувані та постачувані об'єкти бібліотеки

Див. також

• Тексти модулів
• Структура модуля