Разработка на usp слое

[Murlin]

Доброго времени суток.

Дело в том что я решил включить разработку на usp слое для наших местных доработок, но второй программист почему то очень против.
Разрешите наш спор!
На сегодняшний день мы имеем готовый функционал на usr слое, который периодически должен будет обновляться, но заноситься он сравнением.
Работая на usr слое мы переписываем написанный функционал и затираем его, кроме того имеем очень много функционала который нам пока не нужен или вообще не нужен.
Не имея лучшего я предложил делать наши местные доработки на usp слое.
Возник спор. Мне не объяснили фактически какие минусы мы будем иметь кроме того что делать этого не нужно.
Вот собственно сообщение:

Цитата:

Для начала, зачем вообще нужны слои: они позволяют разделить разработку, ведущуюся разными организациями и/или для разных рынков/клиентов. т.е., скажем, вынести базовый (общий для всех) функционал на слой sys, какие-то региональные доработки – на слой gls, доработки отдельных внедренцев - на слои var/bus, доработки под конкретного клиента, а то, что сам клиент для себя лично дорабатывает, – на слой usr. Слои позволяют четко разнести модификации, сделанные разными компаниями или сторонами (внедренцем и заказчиком), кроме того, поскольку в Аксапте очень много завязок на внутренние идентификаторы объектов приложения (таблиц, полей, типов, классов, etc), для слоев выделяются непересекающиеся диапазоны идентификаторов, например, для sys - 1..16000, для usr - 50001-65000 (примерно, последние несско сотен используются объектами и типами ядра).

За счет этого, если одновременно создавать новые объекты на разных слоях и затем свести эти слои в рамках одного приложения, такие объекты гарантированно не пересекутся по идентификаторам (остается вариант пересечения по именам, но это контролировать проще, скажем, за счет использования префиксов/суффиксов). Это позволяет системе «не путаться» в них и рассматривать как различные объекты, а не как модификации одного и того же объекта. При модификации же объекта из нижележащего слоя он «поднимается» на слой, на котором ведется текущая разработка, с сохранением исходного идентификатора, и система при выполнении приложения использует копию объекта из самого верхнего слоя.

Таким образом, разведение функционала на слои и использование непересекающихся диапазонов идентификаторов позволяет четко отделить базовые разработки от собственных и, кроме того, позволяет относительно легко переносить собственные модификации при изменении приложения в "нижележащих" слоях: выпустили новый SP - слои с ним можно подложить в приложение вместо существующих, создать проект сравнения слоев на базе модификаций на том же usr-слое и быстренько эти модификации обновить для соответствия тому, что появилось в SP. Это удобно, когда изменения в "нижележащих" слоях происходят относительно часто, скажем, раз в полгода-год. К слову, для облегчения выпуска обновлений кроме «обычных» существуют и так называемые patch-слои; их имена соответствую именам «обычных» слоев, только заканчиваются на “p”: sys – syp, gls – glp, cus – cup, usr – usp. Ядро считает patch-слои расположенными «выше» соответствующих «обычных» слоев, т.е. при определении того, какую копию модифицированного объекта использовать, копия с patch-слоя имеет приоритет над копией из соотв. «обычного» слоя. Так вот, patch-слои не предназначены для «обычной» разработки, поскольку они используют тот же диапазон идентификаторов, что и соответствующий «обычный» слой; назначение patch-слоев – удобная форма выпуска исправлений для того или иного «основного» слоя: такие исправления, собранные в виде слоя, в отличие от исправлений в виде файлов экспорта (XPO), позволяют клиентам легко и быстро их накатывать. Если же вести разработку одновременно и в обычным, и в patch-слое, то объекты приложения в них почти наверняка пересекутся по идентификаторам, что может привести к непредсказуемым последствиям.

Например, в копии приложения без patch-слоя (приложение А) в «обычном» слое (usr) создается новый числовой тип данных IntType1, в таблицах создаются поля на базе этого типа. В это же время в другой копии исходного приложения с patch-слоем (приложение В) на этом слое создается строковый тип данных StrType2 с идентификатором, совпадающим с IntType1 из приложения А. В этом случае, если потом в приложение В подложить измененный usr-слой из приложения А, система подумает, что IntType1 и StrType2 – это один и тот же объект, а его копия на usp-слое – всего лишь модификация исходного объекта, а не отдельный не связанный с исходным тип.

При очередной синхронизации словаря данных будут созданы поля не целочисленного типа IntType1, с строгого типа StrType2, формы и код приложения начнут работать некорректно, полезут ошибки, но исправить их будет сложно, потому что нельзя будет просто удалить тип StrType2 с usr-слоя: возможно, на него уже ссылаются другие табличные поля или элементы управления на формах/отчетах. Аналогичные «сюрпризы» могут произойти при пересечении идентификаторов классов. В приложении методы классов ссылаются на класс, к которому они относятся, по идентификатору.

Если на слое usr в приложении А есть класс Class1 с определенным идентификатором и методом run(), выполняющим основную логику класса, в приложении В на usp-слое есть класс Class2 с таким же идентификатором и «своим» методом run(), то при подкладывании в приложение В usr-слоя из приложения А класс Class1 перестанет работать корректно, потому что система посчитает, что эти два класса – копии одного и того же (исходная и модифицированная), и будет для класса Class1 вызывать метод run() из Class2…

Еще раз: patch-слои предназначены только для выпуска обновлений и исправлений для уже созданных объектов приложения, но никак не для самостоятельной разработки на этих слоях, предусматривающей создание новых объектов приложения. Непонятно, какие плюсы кто-либо мог увидеть в разработке на usp-слое - по-моему, от этого могут быть лишь одни проблемы.

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

Разве таже проблема с дублированием идентификаторов не будет возникать без usp слоя?