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