|
v8: Методика написания конфигураций на УФ, общие модули. Подскажите неофиту УФ | ☑ | ||
---|---|---|---|---|
0
ignorant
27.06.13
✎
15:26
|
КМК, смысл ОБЩЕГО модуля (ОМ) в том, что к его функциям идет многократное обращение из различных ОБЪЕКТОВ конфигурации.
В типовых конфигурациях на УФ (БСП, УТ) всё обстоит немного СОВСЕМ не так  : Для обслуживания объекта конфигурации создаются пачка ОМ. Например, к Справочнику ФизическиеЛица : ФизическиеЛица ФизическиеЛицаКлиент ФизическиеЛицаКлиентСервер Обращений из ДРУГИХ объектов к этим модулЯм мало, зато «читабельность» конфигурации страдает от большого числа мелких по размеру ОМ. Функции в клиентских модулях часто однострочные и имеют задачу вызвать код на сервере, вроде Процедура УстановитьРабочийКаталогПользователя(ИмяКаталога) Экспорт ОбщегоНазначенияВызовСервера.ХранилищеОбщихНастроекСохранитьИОбновитьПовторноИспользуемыеЗначения("ЛокальныйКэшФайлов", "ПутьКЛокальномуКэшуФайлов", ИмяКаталога); КонецПроцедуры Можно ведь было попробовать : - разместить функции, обслуживающие объект в форме / модуле / Модуле менеждера объекта с директивами места выполнения кода? - сгруппировать функции каким-то другим способом (например:подсистема + место выполнения) для уменьшения числа ОМ. Вопросы: - Насколько оправдана такая архитектура конфигураций? - СтОит ли ориентироваться на типовые при разработке своих объектов? Спасибо за внимание. |
|||
1
Maxus43
27.06.13
✎
15:29
|
БСП, УТ... в них маленькие, а в УПП очень даже большие. И делаются типовые можно сказать по одному шаблону, с расчетом на УППырище здоровое
|
|||
2
ignorant
27.06.13
✎
15:30
|
УПП на управляемых формах ещё не видел.
Разве есть такое в природе?... |
|||
3
1Cv8_accepted
27.06.13
✎
15:35
|
(0) Во-первый, процедуры и функции в общих модулях собраны не по принадлежности их какому-то объекту, а по функциональному назначению. Во-вторых, модуль менеджера объекта предназначен для другого: например, для выполнения функций и процедур без явной инициализации объекта.
На типовые конфигурации ориентироваться можно, когда уверен, что хотя бы способен отличить хороший код (архитектуру) от плохого. |
|||
4
Maxus43
27.06.13
✎
15:36
|
(2) готовится. УПП 2.0 вестимо
|
|||
5
acsent
27.06.13
✎
15:38
|
модуль менеджера - это чисто сервер
|
|||
6
Поросенок Петр
27.06.13
✎
15:38
|
(0) А кто сказал что ФизическиеЛица это один объект конфигурации?
|
|||
7
acsent
27.06.13
✎
15:39
|
Хоть вложенность вызовов и зашкаливает (видел до 15) но читабельность и доработка на уровне
|
|||
8
ignorant
27.06.13
✎
15:46
|
(3) Вот и пытаюсь определить своё мнение.
Пока меня архитектура типовых сильно смущает. Гложут сомнения: то ли я не сильно глубоко въехал, то ли архитектура СЛИШКОМ мудрёная. |
|||
9
Maxus43
27.06.13
✎
15:47
|
(8) "Лучше безобразно, но однообразно" (с) Нуралиев
|
|||
10
acsent
27.06.13
✎
15:48
|
(8) как минимум 3 разным модуля означают 3 разных контекста вызова.
Не принято смешивать, а клиент-серверные модули вообще зло |
|||
11
acsent
27.06.13
✎
15:48
|
- сгруппировать функции каким-то другим способом (например:подсистема + место выполнения) для уменьшения числа ОМ.
собственно так и сделано |
|||
12
ignorant
27.06.13
✎
15:52
|
(11) Сделано как раз НЕ ТАК:
сгруппировано ОБЪЕКТ + место выполнения. И если задача ОМ - обслуживание объекта ТОЛЬКО (больше к ОМ никто не обращается), стОит ли выносить этот функционал в ОМ вообще? Не правльнее ли размежать его в объекте? |
|||
13
ignorant
27.06.13
✎
15:52
|
"размежать" = "размещать"
|
|||
14
samozvanec
27.06.13
✎
16:01
|
тиражка штампуется с расчетом на то, чтобы текущая архитектура не привела к коллапсу в будущем. если ты уверен в законченности своих фантазий и можешь определить достаточную степень гибкости архитектуры, то никто не мешает тебе вместо глЗначениеПеременной("ТекущийПользователь") дергать отовсюду параметр сеанса и, соответственно, такой глобальной функции не делать.
|
|||
15
olegves
27.06.13
✎
16:01
|
(12) логично.
ОМ нужОн, например, для контроля остатков по регистру при проведении разными документами, хотя и тут можно использовать модуль Регистра Есть, правда, ОМ с признаком повторного использования - полезно, когда часто получаешь в одной клиентской сессии какие-то данные (я использовал получение данных и КОМ-соединения), кроме того, ОМ, доступные в сеансе КОМ-соединения, а также ОМ для фоновых заданий |
|||
16
ignorant
27.06.13
✎
16:16
|
(14)С параметрами сеанса всё намного проще, они не содержат функционал, только ЗНАЧЕНИЯ.
Вопрос - про ОМ и "размазанный" функционал. (15)Варианнтов решения - множество. Задача архитектора - найти компромисс между "правильностью" и "универсальностью" ;) Большое количество ОМ - это КРУТО или это Лень/БоязньНакосячить архитектора?... СЕЙЧАС я бы стремился иметь обозримое число ОМ... |
|||
17
acsent
27.06.13
✎
16:27
|
(12) физлица - это подсистема, посмотри внимательней
|
|||
18
ignorant
27.06.13
✎
16:35
|
(17) Смотрю БСП 2.1.4.25
не _Демо только подсистемы: НастройкаИАдминистрирование СтандартныеПодсистемы |
|||
19
shuhard
27.06.13
✎
17:02
|
(2)[УПП на управляемых формах ещё не видел.
Разве есть такое в природе?...] окстись УПП 1.3 |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |