Персональный блог Игоря Антонова aka "spider_net"

Модули менеджеров прикладных объектов в 1С:Предприятие 8


Рубрика: 1С:Предприятие -> Программирование
Метки: | |
Просмотров: 4314
Модули менеджеров прикладных объектов в 1С:Предприятие 8

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

Совсем иная ситуация с «in-house» решениями. Тут нет кошмара под названием «обновления опять все затерли» и можно выстраивать структуру приложения исходя из своих предпочтений. Вот здесь модули менеджеров прикладных объектов могут принести огромную пользу.

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

Модули менеджеров прикладных объектов позволяют расширить возможности системных менеджеров, снабдив их дополнительным функционалом. Если ты имеешь опыт разработки на объектно-ориентированных языках программирования, то сразу можешь ассоциировать отдельную процедуру/функцию, описанную в модуле менеджера прикладного объекта как метод объекта.

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

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

СписокОсобыхКонтрагентов = КакойТоОбщийМодуль.ПолучитьСписокОсобыхКонтрагентов();

Выглядит весьма не дурно, но теперь попробуем представить себя в шкуре другого разработчика. Как он должен узнать, что функция ПолучитьСписокОсобыхКонтрагентов() описана именно в «КакойТоОбщийМодуль »? Если по названию этого модуля хоть как-то можно провести параллель со справочником «Контрагенты», то все не так плохо.

Хуже, когда модуль называется «СборникФункций» и содержит коллекцию решений на все случаи жизни. Скажу из опыта, что не один новый разработчик не будет ковыряться в такой «каше» ища нужную функцию. А если и будет, то трижды проклянет человека, кто эту функцию туда засунул.

Вот тут менеджеры модулей прикладных объектов могут сослужить хорошую службу. Если описать нашу функцию с хитрым алгоритмом поиска в модуле менеджера прикладного объекта «Справочники.Контрагенты», то вызывать ее будем так:

СписокОсобыхКонтрагентов = Справочники.Контрагенты.ПолучитьСписокОсобыхКонтрагентов();

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

Резюме

  • Модуль менеджера прикладного объекта позволяет расширить функциональность системных менеджеров;
  • Модуль менеджера приносит в код чуточку красоты и логичности;
  • Модуль менеджера стандартная фича и не нужно стеснятся ей пользоваться;
  • Нет ничего лучше, когда код располагается в специально-предназначенном для этого месте;

  • Комментариев: 4 RSS

    Блин, а я как-то раньше об этом и не думал. Озадачен... :)Сам имею обыкновение сгружать код в общие модули с названием аля "ОбщиеСерверныеФункции". Сразу вспоминается CMS Drupal 6 и его общие функции в файле под названием common.inc, содержащий не один десяток тысяч строк кода. Весь код, который не был каким-либо образом структурирован, взяли и сгрузили в один файл. Попробуй потом разобраться в этом "наследии"... :-D

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

    Почему же тогда в типовых конфигурациях подобные вещи редко применяются?

    2Ирина

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

    Оставьте комментарий!
    comments powered by HyperComments