Выбор способа проектной доработки#
Общая схема выбора#
Выбор способа проектной доработки выполняется по принципу перехода от наименее трудозатратного и рискованного варианта к более сложному:
Настройка без кода. Проверяется в первую очередь, если требование можно закрыть стандартными настройками системы.
Характеристики. Если настроек недостаточно, оценивается возможность использования объектных или универсальных характеристик.
Точка расширения. Применяется, когда необходимо внедрить проектную логику в предусмотренном для этого месте.
Проектное переопределение. Используется, когда требуется изменить поведение типового объекта без прямого изменения типовой поставки.
Новый проектный объект. Создается, если требуется самостоятельная функциональность, которую нельзя корректно реализовать через настройки, характеристики или расширение существующего объекта.
Модификация типовой поставки. Допускается только при невозможности использования предыдущих способов и требует обязательного согласования.
Такой порядок позволяет выбрать наиболее сопровождаемое и наименее рискованное решение для проектной доработки.
Когда использовать настройку через интерфейс#
Настройку через интерфейс следует использовать, если изменение относится к поведению или отображению уже существующей функциональности и не требует изменения схемы базы данных или серверного кода.
Через настройки следует реализовывать:
подключение печатных форм к типу объекта;
настройку доступности печатных форм по состояниям, профилям и условиям;
настройку вкладок и закладок на типе объекта;
настройку переходов состояний;
подключение JEXL-скриптов в поддерживаемых местах применения;
настройку объектных и универсальных характеристик;
значения по умолчанию для характеристик;
правила проверки и ограничения выбора, если они поддерживаются соответствующим механизмом;
переименование или скрытие элементов интерфейса, если это допустимо через настройки.
Настройка через интерфейс предпочтительна для изменений, которые часто корректируются функциональными специалистами и не являются частью критичной серверной бизнес-логики.
Когда использовать объектные и универсальные характеристики#
Объектные и универсальные характеристики следует использовать для дополнительных проектных данных, если:
атрибут нужен для хранения дополнительной информации по объекту;
атрибут не является обязательной частью типовой структуры класса;
атрибут может отличаться по типам объектов или группам объектов;
изменение должно выполняться без пересборки проекта и без изменения схемы БД;
атрибут не используется в высоконагруженной обработке;
атрибут не требует сложных индексов, внешних ключей и массовых операций на уровне БД.
Основной способ хранения объектных и универсальных характеристик — JSON-контейнер jObjAttrs_dz. Детальнее в разделе Работа с объектными характеристиками.
Характеристики не следует использовать как замену полноценной модели данных, если поле:
участвует в ключевой бизнес-логике;
используется в массовой обработке большого объема данных;
должно иметь индекс в БД;
должно участвовать в сложных реляционных запросах;
используется как обязательная связь между сущностями;
требуется для интеграций с жесткими требованиями к структуре данных;
должно быть частью основной структуры бизнес-объекта.
В этих случаях атрибут должен проектироваться в коде как часть ODM/ORM-модели или выноситься в отдельный проектный класс.
Когда использовать код и ODM#
Разработка в коде используется, если требование невозможно корректно реализовать настройкой.
Код и ODM следует использовать, если требуется:
создать новый проектный класс;
создать новую коллекцию или табличную часть;
добавить поле, которое участвует в основной бизнес-логике;
обеспечить высокую производительность чтения или записи;
использовать поле в индексах, массовых запросах или реляционных соединениях;
реализовать сложную валидацию;
реализовать серверную обработку в Api, Avi, Pkg или Lib;
реализовать интеграционный обработчик;
реализовать функциональность, которая должна поставляться и сопровождаться как часть проектного модуля.
Внимание
Физическое добавление колонок напрямую в БД без ODM, миграции или поддерживаемого механизма регистрации запрещено.
Когда использовать JEXL#
JEXL-скрипты используются для короткой прикладной логики в местах, где система поддерживает выполнение JEXL.
JEXL допустим для:
условий доступности;
переходов состояний;
простых вычислений;
фильтрации печатных форм;
настройки поведения, которое должно изменяться без пересборки проекта;
вызова уже реализованных Scala-методов.
JEXL не следует использовать для:
сложной бизнес-логики большого объема;
массовой обработки данных;
логики, требующей строгого контроля транзакций;
логики, которую сложно тестировать и сопровождать;
реализации критичных интеграционных сценариев вместо серверного кода.
Если JEXL становится большим, содержит много ветвлений или дублируется в нескольких местах, логику необходимо перенести в серверный код, а из JEXL оставить только вызов подготовленного метода.
Когда использовать точку расширения#
Точка расширения используется, если типовая логика предоставляет поддерживаемое место для подключения проектной обработки.
Точку расширения следует использовать до проектного переопределения, если она позволяет решить задачу.
Точки расширения подходят для:
добавления проектных проверок;
дополнения стандартной обработки;
расширения метаданных;
подключения проектной логики в заранее предусмотренных местах;
изменения поведения без копирования типового кода.
Дополнительная информация в разделах Точки расширения и Как создать точку расширения.
Когда использовать проектное переопределение#
Проектное переопределение используется, если нужно изменить или дополнить поведение типового объекта, но прямое изменение типового кода недопустимо.
Проектное переопределение допустимо, если:
стандартная логика не закрывает проектное требование;
для нужного сценария нет подходящей настройки или точки расширения;
изменение локализовано в конкретном Api, Avi, Pkg или Lib;
проектная команда понимает, какие методы переопределяются и как они могут измениться при обновлении;
переопределение покрыто тестами.
Проектное переопределение не должно использоваться как способ полностью переписать типовой объект без необходимости.
Перед созданием переопределения нужно проверить, есть ли точка расширения. Если точка расширения есть, использовать следует ее.
Дополнительная информация в разделе Проектные расширения.
Когда создавать проектную копию типового объекта#
Проектная копия типового объекта создается только в случаях, когда объект должен развиваться независимо от типовой поставки и проектная логика не должна зависеть от изменений типового объекта.
Проектная копия допустима, если:
требуется существенно изменить состав атрибутов, выборок или операций;
типовой объект используется как образец, но проектный сценарий отличается по жизненному циклу;
прямое переопределение приведет к большому объему нестабильного кода;
требуется избежать перезаписи настроек типовыми DataInstall-скриптами.
Проектная копия должна иметь проектный модуль и проектное системное имя. Имя копии не должно совпадать с типовым именем и не должно выглядеть как объект типовой поставки.
Краткие примеры выбора способа реализации#
Сценарий |
Рекомендуемый способ |
|---|---|
Нужно добавить комментарий к документу для одного проекта |
Объектная или универсальная характеристика |
Нужно добавить поле, по которому выполняются частые SQL-отчеты |
Атрибут в ODM или отдельный проектный класс |
Нужно ограничить доступность печатной формы по состоянию |
Настройка печатной формы или JEXL в поддерживаемом месте |
Нужно добавить проверку перед переходом состояния |
Точка расширения или JEXL, если сценарий простой |
Нужно изменить стандартное поведение метода Api |
Точка расширения, если есть; иначе проектное переопределение |
Нужно создать новый проектный справочник |
Новый проектный класс с проектным префиксом |