23 мая 2017 г.
Как не запутаться в зависимостях объектов ПИ
Уже миллион раз успел пожалеть, что сделал в Гедымине режим добавления объектов в ПИ "с зависимыми". Это мощная функция, которая требует от применяющего досконального знания теории реляционных баз данных, структуры конкретной БД, внутреннего устройства своего прикладного решения.
Добросовестная разработка с использованием данной галки требует следования определенной последовательности операций:
- Добавить объект в ПИ с зависимыми.
- Открыть список ПИ. Найти нужное и по-порядку, по списку входящих в него объектов, проверить что именно добавилось. Убрать лишнее.
- Открыть список зависимостей для выбранного ПИ и проверить какие зависимости добавились. При необходимости изменить.
- Сохранить ПИ в репозиторий.
- Взять чистый эталон и загрузить на него пакет (каждый функционально завершенный и обособленный модуль должен быть оформлен в виде пакета).
- Протестировать работоспособность загруженного пакета.
Почему?
Представим, что за основую для разработки прикладного пакета мы взяли старую клиентскую базу с данными:
- В такой базе может присутствовать целый букет устаревших, временных, давно забытых ПИ. При добавлении "с зависимостями" они подхватятся и затянутся в список зависимых ПИ.
- В таблицах на таких БД могут присутствовать устаревшие, уже не используемые поля. Мало того, что они затянутся в ПИ, так еще затянутся и объекты на которые они ссылаются.
- Устаревшие скрипт-функции могут привести к тому, что код, работающий на разработочной базе, не будет работать на чистой базе, собранной из актуальных ПИ.
Прозаическая реальность оказалась далека от ожиданий. Добавление с зависимостями применяется чтобы на скорую руку получить результат, а какого он будет качества мало кого волнует. Потом, когда выясняется что ПИ не устанавливается, требуется затратить в 10 раз больше усилий, чтобы распутать зависимости между объектами и файлами ПИ.
Если не уверен в себе и на все 100% не понимаешь что происходит "под капотом" системы, то каждый объект надо добавлять в ПИ вручную, по-отдельности, в порядке реляционной зависимости. Что особенно ценно, при добавлении вручную маловероятны ситуации "запутывания" связей между объектами или файлами ПИ.
После автоматического добавления с завимостями следует тщательно изучить и скорректировать список зависимых ПИ. Общее правило тут такое: чем меньше зависимостей, тем лучше.
Пример: пусть мы создаем небольшое прикладное решение, расширяющее стандартный пакет Зарплата и Кадры. Назовем его Наряды.
- Поскольку решение не велико, то объекты разобъем по следующим ПИ:
- GS.Зарплата.Наряды.Метаданные -- домены, таблицы, триггеры и т.п.
- GS.Зарплата.Наряды.Хранилище -- экранные формы.
- GS.Зарплата.Наряды.Макросы -- перекрытые методы, локальные макросы форм.
- GS.Зарплата.Наряды.Отчеты -- печатные формы.
- Зависимости настроим следующим образом:
- GS.Зарплата.Наряды.Метаданные зависит от пакета GS.Зарплата.
- GS.Зарплата.Наряды.Хранилище зависит от GS.Зарплата.Наряды.Метаданные.
- GS.Зарплата.Наряды.Макросы зависит от GS.Зарплата.Наряды.Хранилище.
- GS.Зарплата.Наряды.Отчеты зависит от GS.Зарплата.Наряды.Макросы.
- Создадим пакет GS.Зарплата.Наряды и сделаем его зависимым от GS.Зарплата.Наряды.Отчеты. Обратите внимание, что нет необходимости в пакете ставить зависимость от всех ПИ нашего решения, так как между ними итак уже присутствуют зависимости.
- Сохраним ПИ в файлы и расположим их в подкаталоге Наряды в папке Зарплата и кадры.
- Запишем в репозиторий.
- Подключимся к чистой эталонной базе данных ипоставим на загрузку пакет GS.Зарплата.Наряды. Проверим, чтобы загрузка не кидала ошибок. Проверим работоспособность после загрузки.
Подписаться на:
Сообщения (Atom)
