Azimut Framework
  • О платформе Azimut
  • Концепция
    • Суть разработки на Azimut
    • Компиляция метаданных
    • Наследование метаданных
    • Подсистемы
    • Проекты и релизы
    • Расширяемость
  • Начало работы
    • Системные требования
    • Установка
  • Документация
    • Основные объекты
      • Сущность
      • Контекст
        • Контекст в выборках
        • Контекст в представлениях
      • Представление
      • Выборка
        • Фильтры и параметры отбора
      • Web формы
    • Биндинги параметров Sql скрипта
      • Биндинг Идентификатор документа
      • Биндинг Поле представления
      • Биндинг Строка
    • Автозадачи по расписанию
      • Sql to WebRequest
      • Обработка отчетов
      • Пакетное сканирование документов
    • Шаблон ХП
    • Главное меню
    • Вопросы-ответы
      • Как удалить пункт меню
      • Как удалить объект конфигурации
      • Как в выборку добавить параметр отбора
      • Как редактировать выборку прямо в гриде
    • Видео
    • Устранение неисправностей
  • API
    • Возврат ошибок
  • Расширение Платформы
    • Разработка дополнений
      • Расширение API
      • Подключение любой dll
Powered by GitBook
On this page
  • Наследование коллекций
  • Ключ наследования коллекций
  • Абстрактные объекты

Was this helpful?

  1. Концепция

Наследование метаданных

PreviousКомпиляция метаданныхNextПодсистемы

Last updated 5 years ago

Was this helpful?

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

Наследование коллекций

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

В дочернем объекте мы только добавляем его специфические поля или переопределяем поля родительского объекта.

Ключ наследования коллекций

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

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

Абстрактные объекты

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

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

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

Такое иерархическое наследование следует использовать руководствуясь здравым смыслом. Например, не стоит создавать родительский объект "Справочники" и наследовать от него все справочники. Более рационально разнести эти справочники по своим . В данном примере это подсистема Коммуникация - чаты, боты, общение пользователей.

Замечание: кстати, объекты являющиеся "папками" , всегда абстрактные.

компиляции
подсистемам
подсистем