XDTO — это просто, часть 3

Краткое содержание предыдущих серий

Первый две статьи были посвящены обзорной экскурсии по XDTO, введению в схемы XML, базовым операциям по импорту их в конфигурацию.

Собственно, статьи:

1. Первая серия
2. Вторая серия

При написании данной статьи, я столкнулся с небольшой дилеммой. Я планировал описать устройство объектов и их взаимодействие с теоретической точки зрения. Но в комментариях мне обоснованно пояснили, что лучшее объяснение — это пример. Языки программирования начинают учить с "hello world" и уже потом лезут в теоретические дебри. Я с этим согласен. Когда нет конкретного примера, который можно пощупать, то вникать в кучу слов неинтересно, да и трудно. Я попробую совместить в статье кусок теории, но подкрепить его небольшим примером кода, показывающим описанные в статье моменты. Возможно, получится сумбурно, т.к. я пока не до конца понимаю структуру будущей статьи.

И все-таки, начнем не с кода, а опять, с описания компонентов подсистемы XDTO.

Компоненты подсистемы XDTO

Нам не повезло с документированием подсистемы. Совершенно непонятно — откуда у нее растут ноги и с чего начинать работу с ней. Давайте попробуем разобраться.

Как я уже говорил ранее, в основе всего лежит модель данных — перечень прикладных типов, которыми мы будем оперировать при работе с XDTO. Каждый объект XDTO создается фабрикой, которая умеет создавать объекты тех типов, которые содержатся в модели данных фабрики. Итак, есть четко выделенные понятия — модель данных, фабрика, объект. Что в начале — курица или яйцо?

Пакет XDTO

Самый "первичный" объект во всей подсистеме, это пакет XDTO. Именно от него, растут все связи. С него и начнем. Почему он? Потому, что модель данных — это ни что иное, как массив пакетов XDTO. А модель, как я уже говорил — это наше все.

Что такое пакет и что такое ветка ПакетыXDTO

Все наверняка видели в дереве конфигурации ветку ПакетыXDTO. Что это и зачем оно нужно? Оказывается, оно в-общем-то и не нужно 🙂 Использовать XDTO можно и без описания пакетов в этой ветке. Наличие пакетов, зашитых в конфигурацию совсем не обязательно. Ветка эта нужна для совсем определенного круга прикладных задач. По большому счету — вспомогательное средство работы с XDTO.

Теперь, еще раз основной тезис:

Фабрика может создавать объекты только тех типов, которые входят в модель данных этой фабрики.

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

Данная автоматически созданная фабрика, доступна в коде, как глобальная переменная с именем ФабрикаXDTO.

Все пакеты, перечисленные в ветке "ПакетыXDTO" включаются в модель данных конфигурации. Это значит, что глобальная фабрика конфигурации может создавать объекты тех типов, которые описаны в данных пакетах. Например, это позволяет использовать наши собственные объекты совместно с платформенными — можно включать наши объекты в стандартные "СпискиЗначений" и "ТаблицыЗначений".

Устройство пакета

Рассмотрим пакет поближе: пакет представляет собой логически цельный набор типов. У этого набора типов обязательно есть пространство имен, позволяющее уникально идентифицировать пакет. Если вернуться к схемам XML, то пакет — это схема. С рядом допущений, конечно, но тем не менее, ближайший "не 1С-овский" аналог пакета — это схема XML.

Пакет включает в себя описания типов бизнес-объектов, которыми мы собираемся оперировать. Типы бывают простые и составные, об этом мы уже говорили ранее. Кроме того, пакет содержит вспомогательные средства трансляции имен переменных с языка XML на язык 1С:Предприятия и обратно (см. статью 2).

При разработке пакетов я не пользуюсь стандартным редактором, поэтому, наверное, не буду его описывать. Во-первых, боюсь чего-то напутать, во-вторых, он на 90% дублирует понятия из собственно схем XML. Если вы знаете, как в принципе сделать схему (например в Liquid), то работа со стандартным редактором, скорее всего, не вызовет сложных вопросов.

Что более важно, так это то, какие понятия пакет XDTO привносит в обиход программиста, использующего XDTO. Понятия следующие:

1. ТипЗначенияXDTO
2. ТипОбъектаXDTO
3. ЗначениеXDTO
4. ОбъектXDTO
5. СписокXDTO

Мы говорили о том, что типы бывают простыми и составными. Так вот, простой тип, это ТипЗначенияXDTO, а ЗначениеXDTO, это, собственно, значение этого простого типа. Как тип и экземпляр типа. Тип значения — "Число", экземпляр типа — "5". Тип значения — "Строка", экземпляр типа — "Привет". С объектом XDTO все то же самое, но применительно к составному типу.

Со списком сложнее. Если какому-либо свойству в том или ином типе задана верхняя граница, отличная от единицы, то это значит, что данное свойство может повторяться в объекте несколько раз. Таким образом, СписокXDTO представляет собой способ манипулирования множеством объектов заданного типа.

Если мы посмотрим в стандартный редактор пакетов, то увидим строгое разделение на "Типы значений" и "Типы объектов".

Встраивание пакетов в конфигурацию

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

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

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

Масло масляное

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

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

Я очень не люблю, когда имена переменных совпадают с их типами. Звучит ужасно:

ТаблицаЗначений = Новый ТаблицаЗначений;
Массив = Новый Массив;

То же получилось и с фабрикой. Это такой объект, который нужен, мягко говоря, не каждую секунду работы программы. Люди годами пишут под 1С, даже не касаясь каких-то там фабрик. Зачем нужна семантика постоянно висящей переменной непонятно. Лучше и правильнее было бы, на мой взгляд создать метод, что-то вроде "ПолучитьФабрикуXDTOТекущейКонфигурации()". В результате имеется четкое понимание, что мы хотим использовать конкретную системную фабрику, но имя переменной, с которой мы будем работать мы придумаем сами. Да, тип этой переменной будет ФабрикаXDTO.

В результате, документация моментально становится проще, за счет исчезновения фраз "Глобальный объект "ФабрикаXDTO" с типом "ФабрикаXDTO"".

Что-то мы отвлеклись…. Имеем то, что имеем, а именно — глобальный объект, фабрику, которая умеет создавать объекты наших собственных типов. Поехали дальше!

Сериализация XDTO

Вот то, что призвано сделать нашу жизнь лучше, но, иногда, делает ее сложнее. Сериализация и десериализация, это сама цель создания вообще всей этой замороки с XDTO. Ведь что мы хотим делать? Мы хотим передавать объекты куда-либо и получать их обратно. Все объекты в конечном итоге превращаются в XML. Получается, что все, что нам нужно — это автоматическая запись некоторого бизнес-объекта в XML и чтение его обратно. Вот здесь, на этом самом месте, нужно провести жирную красную линию и разделить два отдельных механизма. Первый — это создание объектов XDTO и их сериализацию в/из XML. Второй — получение из XDTO объектов прикладного языка: строк, ссылок, дат и т.п.
Итак, жирная красная линия: