v8: Методика написания конфигураций на УФ, общие модули. Подскажите неофиту УФ #670865

КМК, смысл ОБЩЕГО модуля (ОМ)  в том,  что к его функциям  идет многократное обращение из различных ОБЪЕКТОВ  конфигурации. В типовых конфигурациях на  УФ (БСП, УТ) всё обстоит немного СОВСЕМ не так  : Для обслуживания объекта  конфигурации создаются пачка ОМ. Например, к Справочнику ФизическиеЛица  : ФизическиеЛица ФизическиеЛицаКлиент ФизическиеЛицаКлиентСервер Обращений из ДРУГИХ объектов к этим модулЯм мало,  зато «читабельность» конфигурации страдает от большого числа мелких по размеру ОМ. Функции в клиентских модулях часто однострочные и имеют задачу  вызвать код на сервере,  вроде Можно ведь было попробовать : - разместить  функции, обслуживающие объект в форме / модуле / Модуле менеждера объекта  с директивами места выполнения кода? - сгруппировать функции  каким-то другим способом (например:подсистема  + место выполнения) для уменьшения числа ОМ. Вопросы: - Насколько оправдана такая архитектура конфигураций? - СтОит ли ориентироваться на типовые при разработке своих объектов? Спасибо за внимание.

БСП, УТ... в них маленькие, а в УПП очень даже большие. И делаются типовые можно сказать по одному шаблону, с расчетом на УППырище здоровое

УПП на управляемых формах ещё не видел. Разве есть такое в природе?...

Во-первый, процедуры и функции в общих модулях собраны не по принадлежности их какому-то объекту, а по функциональному назначению. Во-вторых, модуль менеджера объекта предназначен для другого: например, для выполнения функций и процедур без явной инициализации объекта. На типовые конфигурации ориентироваться можно, когда уверен, что хотя бы способен отличить хороший код (архитектуру) от плохого.

готовится. УПП 2.0 вестимо

модуль менеджера - это чисто сервер

А кто сказал что ФизическиеЛица это один объект конфигурации?

Хоть вложенность вызовов и зашкаливает (видел до 15) но читабельность и доработка на уровне

Вот и пытаюсь определить своё мнение. Пока меня архитектура типовых сильно смущает. Гложут сомнения: то ли я не сильно глубоко въехал, то ли архитектура СЛИШКОМ мудрёная.

"Лучше безобразно, но однообразно" (с) Нуралиев

как минимум 3 разным модуля означают 3 разных контекста вызова. Не принято смешивать, а клиент-серверные модули вообще зло

- сгруппировать функции  каким-то другим способом (например:подсистема  + место выполнения) для уменьшения числа ОМ. собственно так и сделано

Сделано как раз НЕ ТАК: сгруппировано ОБЪЕКТ + место выполнения. И если задача ОМ - обслуживание объекта ТОЛЬКО (больше к ОМ никто не обращается), стОит ли выносить этот функционал в ОМ вообще? Не правльнее ли размежать его в объекте?

"размежать" = "размещать"

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

логично. ОМ нужОн, например, для контроля остатков по регистру при проведении разными документами, хотя и тут можно использовать модуль Регистра Есть, правда, ОМ с признаком повторного использования - полезно, когда часто получаешь в одной клиентской сессии какие-то данные (я использовал получение данных и КОМ-соединения), кроме того, ОМ, доступные в сеансе КОМ-соединения, а также ОМ для фоновых заданий

С параметрами сеанса всё намного проще, они не содержат функционал, только ЗНАЧЕНИЯ. Вопрос - про ОМ и "размазанный" функционал. Варианнтов решения - множество. Задача архитектора - найти компромисс между "правильностью" и "универсальностью" ;) Большое количество ОМ - это КРУТО или это Лень/БоязньНакосячить архитектора?... СЕЙЧАС я бы стремился иметь обозримое число ОМ...

физлица - это подсистема, посмотри внимательней

Смотрю БСП 2.1.4.25 не _Демо только подсистемы: НастройкаИАдминистрирование СтандартныеПодсистемы

[УПП на управляемых формах ещё не видел. Разве есть такое в природе?...] окстись УПП 1.3