Расширения и переопределения

Расширения и переопределения#

Точки расширения#

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

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

Точки расширения должны применяться для:

  • дополнения стандартной обработки;

  • подключения проектных проверок;

  • изменения поведения в специально предусмотренных местах;

  • расширения метаданных, если механизм предоставляет такую возможность.

При использовании точки расширения необходимо описать:

  • какая точка расширения используется;

  • для какого бизнес-сценария она подключена;

  • какие данные она изменяет или проверяет;

  • какие ограничения есть у проектной логики;

  • какие тесты подтверждают корректность работы.

Simple Extensions#

Классы-расширения используются для локального подключения проектной логики к стандартным объектам.

При использовании Simple Extension необходимо:

  • явно указать, какой объект расширяется;

  • не дублировать типовую логику без необходимости;

  • описать назначение расширения;

  • проверить работу после обновления типового объекта.

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

Проектное переопределение#

Проектное переопределение должно быть минимальным.

При переопределении метода необходимо:

  • сохранить вызов стандартной логики, если нет причины полностью заменить поведение;

  • описать, что именно изменено;

  • указать задачу или основание изменения;

  • покрыть сценарий тестами;

  • проверить влияние обновлений типового метода.

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

Проектные копии типовых объектов#

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

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

Перед созданием проектной копии необходимо проверить:

  • можно ли закрыть требование настройкой;

  • есть ли подходящая точка расширения;

  • можно ли использовать проектное переопределение;

  • какие типовые DataInstall-скрипты могут повлиять на исходный объект;

  • какие риски возникнут при обновлении типовой поставки;

  • как будет сопровождаться проектная копия.

Изменение базовых справочников#

Изменение базовых справочников и их логики требует отдельного анализа.

Если требуется изменить базовый справочник, сначала необходимо определить, что именно изменяется:

  • пользовательское наполнение справочника;

  • настройки отображения;

  • печатные формы;

  • дополнительные характеристики;

  • переходы состояний;

  • бизнес-логика Api/Pkg;

  • структура хранения.

Пользовательское наполнение и проектные настройки могут быть изменены через интерфейс или проектный DataInstall, если это не конфликтует с типовой поставкой.

Изменение типовой структуры, типовой логики или типовых DataInstall-скриптов напрямую не допускается без согласования.

Если базовый справочник нужно развивать независимо от типовой поставки, следует рассмотреть проектную копию или новый проектный справочник.

Риски обновлений#

Проектная логика, завязанная на типовые объекты, должна проверяться при обновлении системы.

Особое внимание требуется, если проектная доработка:

  • наследуется от типового Api или Avi;

  • переопределяет типовой метод;

  • использует типовые атрибуты в JEXL или SQL;

  • расширяет типовую выборку;

  • копирует типовую логику;

  • зависит от типовых DataInstall-скриптов;

  • изменяет стандартное поведение базового справочника или документа.

Перед обновлением необходимо оценить изменения в типовой поставке и выполнить регрессионное тестирование затронутых процессов.

Что нельзя менять напрямую#

Запрещено без отдельного согласования:

  • менять типовые ODM-файлы;

  • менять типовую доменную логику;

  • менять типовые DataInstall-скрипты;

  • править типовые SQL-скрипты поставки;

  • размещать проектный код в доменных файлах, которые перезаписываются кодогенерацией;

  • менять структуру типовой таблицы напрямую в БД;

  • удалять или переименовывать типовые атрибуты;

  • отключать типовые сервисные механизмы, если от них зависят другие модули.

Содержание