Наследование метаданных
Last updated
Last updated
Наследование метаданных это одна из самых важных фич во всей платформе. Наследование позволяет выстраивать иерархию объектов, необходимую для более простого управления проектом. Наследование нужно активно применять (в разумных пределах) для построения красивой и понятной с одного взгляда структуры. Ведь четкая и понятная архитектура напрямую влияет на успех и себестоимость вашего проекта. И настоящая платформа должна обеспечивать возможность усложнения проекта без захламления и загромождения архитектуры. Иначе это не платформа, а просто программа с гибкими настройками.
При работе с конфигурацией следует учитывать что все коллекции параметров всегда наследуются. То есть те параметры которые перечисляются в виде коллекций, например столбцы в сущностях, поля в представлениях, скрипты в контекстах - всегда будут наследоваться в дочерних экземплярах метаданных.
На скриншотах выше показаны два объекта. "Комментарий" - является базовым представлением для всех комментариев в чатах. "Сообщение приватного чата" - более специфичный комментарий, которому необходим набор своих полей. Так вот, когда мы используем в рантайме объект "Сообщение приватного чата", то за счет механизма компиляции в нашем распоряжении будут все эти поля из обоих представлений.
В дочернем объекте мы только добавляем его специфические поля или переопределяем поля родительского объекта.
Такое иерархическое наследование следует использовать руководствуясь здравым смыслом. Например, не стоит создавать родительский объект "Справочники" и наследовать от него все справочники. Более рационально разнести эти справочники по своим подсистемам. В данном примере это подсистема Коммуникация - чаты, боты, общение пользователей.
Все элементы в коллекциях при наследовании переопределяются по нахождению свойств с одинаковым значением. Каких именно свойств - у каждой коллекции оно свое. Например поля представлений переопределяются по свойству Имя. Если у родителя и у дочернего объекта будет поле с одним именем, то в итоге это поле переопределится (поле родительского объекта затрется в дочернем и будет использоваться метаданные дочернего поля).
Обратите внимание на те же скриншоты чуть выше. В обоих объектах есть поле EntityID. В родительском объекте это поле является Внешним ключом. Но в дочернем объекте нам не нужен такой внешний ключ и мы это поле переопределили с другим типом - простой Глобальный идентификатор (Guid). В итоге в рантайме, при использовании объекта "Сообщение приватного чата" поле EntityID будет иметь простой тип Глобальный идентификатор.
Любой объект может быть "абстрактным". Это значит что этот объект нельзя создать в рантайме. Его можно только использовать как контейнер для различных метаданных с целью наследования их в дочерних объектах. Другими словами, такой объект используется лишь как звено в иерархии дерева объектов или как папка.
Рассмотрим пример. Представление "Накладная". Это абстрактное представление, его нельзя открыть, нет такой таблицы. Но от него унаследовано несколько других представлений. Например, Приходная и Расходная накладные. И у приходной и у расходной есть общие поля, такие ка ключ, номер, дата, автор и т.д. Эти поля перечислены один раз в родительском абстрактном объекте Накладная. При этом, как мы уже рассмотрели выше, при необходимости эти поля можно переопределить в дочерних объектах.
Замечание: кстати, объекты являющиеся "папками" подсистем, всегда абстрактные.
