В чём преимущества разработки в нескольких пакетах?
Особое нег(к)одование у меня вызывает разбивка клиентских схем на 5-6 пакетов (файлов).
Нравится
1. Делаем продукт в маркетплейс.
На базе нескольких пакетов можем реализовать разные версии с разным набором функционала.
2. Когда в отдельном пакете реализована интеграция с каким то сервисом (запросы к AP например) можно обновлять только при смене реализации / доработке только этого функционала не трогая базовый.
Иногда приходится разбивать по техническим причинам.
Например, выносить создание VIEW в отдельный пакет, так как в основном пакете их часто надо удалить, чтобы внести какие-то изменения в объекты.
И иногда понимаешь, что эта функциональность пригодится многим клиентам. Тогда сразу реализуешь её в отдельном пакете, чтобы затем использовать в других проектах
Богдан Помазан пишет:
На базе нескольких пакетов можем реализовать разные версии с разным набором функционала.
А можно как-то указать, что в случае определенной версии устанавливать или нет конкретный пакет?
Евгений, здравствуйте.
Во многом, всё зависит от специфики того, что разрабатывается.
Как по мне, главное преимущество — этот отход от монолитного подхода в разработке, разнося функционал в разные пакеты, будет легче обеспечить его отказоустойчивость, обновляемость и, как ранее указали другие пользователи, обратную совместимость с разными версиями/сборками приложения.