12.10.2010, 10:40 | #1 |
Возьми свет!!!
|
Разработка на usp слое
Доброго времени суток.
Дело в том что я решил включить разработку на 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 приложения В слоем из приложения А, то тогда вообще непонятно, зачем в приложении В вести разработку на отдельном слое.
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! |
|
12.10.2010, 11:39 | #2 |
Участник
|
Пробовал так. Это было давно. Сталкивался с глюком, когда работа нового объекта на usp-слое приводила к краху системы.
Для себя "придумал объяснение", что usP - это патч-слой. И разработчики предполагали, что в этом слое будут изменения уже существующих объектов. Поэтому появление новых объектов на этом слое не предусматривали, не тестировали. С тех пор на usp-слое не программирую новых объектов. Возможно, с тех давних пор что-то и изменилось. |
|
12.10.2010, 11:42 | #3 |
Участник
|
Цитата:
Если вы хотите вести разработку в нескольких приложениях, то переход на patch-слой вам не поможет - нужно переходить на слои из разных диапазонов идентификаторов. Например на одном приложении разрабатывать в слое usr, а на другом - в слое var. Но это ли вам надо? Ещё хочу напомнить о такой возможности, как каталог OLD в папке приложения. В который можно безболезненно подложить хоть patch-слой хоть тот же самый. |
|
12.10.2010, 11:43 | #4 |
Участник
|
Цитата:
Особенно, если вы "для себя" прогаете, а не на продажу. Гемор, конечно, но вполне решаемо административными мерами. А вот с этим - согласен. |
|
12.10.2010, 12:51 | #6 |
Возьми свет!!!
|
Цитата:
Сообщение от S.Kuskov
Идентификаторы объектов могут пересекаться только если вести разработку в разных приложениях. И в этом случае абсолютно не важно patch-слой это или тот же самый.
Если вы хотите вести разработку в нескольких приложениях, то переход на patch-слой вам не поможет - нужно переходить на слои из разных диапазонов идентификаторов. Например на одном приложении разрабатывать в слое usr, а на другом - в слое var. Но это ли вам надо? Ещё хочу напомнить о такой возможности, как каталог OLD в папке приложения. В который можно безболезненно подложить хоть patch-слой хоть тот же самый. Вот мне и интересно какие кроме это последствия могут быть?
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! |
|
12.10.2010, 13:01 | #7 |
Administrator
|
Цитата:
А так - конкретно usp-слой - я бы оставил "на всякий случай" как самый верхний слой. Иногда его не хватает.. Например - заливаешь большой xpo и смотришь все изменения (актуально при переходе на сервис-пак/ролап/большой хотфикс)
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: Murlin (1). |
12.10.2010, 13:14 | #8 |
Возьми свет!!!
|
Цитата:
Сообщение от sukhanchik
За исключением того, что импорт в нижний слой объекта, измененного на верхнем слое может себя повести не так как ожидаете. Например объект может глючить. Или все изменения зальются сразу в usp. Т.е. xpo можно (гарантированно без последствий) заливать только в верхний слой (конечно только если объект лежит на нескольких слоях).
А так - конкретно usp-слой - я бы оставил "на всякий случай" как самый верхний слой. Иногда его не хватает.. Например - заливаешь большой xpo и смотришь все изменения (актуально при переходе на сервис-пак/ролап/большой хотфикс) Таблица с usr слоя с другого приложения будет занесена с новым id которого нет ни на usr ни на usp? только что попробовал сделать такое и в принципе все занеслось на usp слой, с нормальным id. Не пробовал пока только заносить в usr.
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! |
|
12.10.2010, 13:19 | #9 |
Administrator
|
Не будет. У usr-usp сквозная нумерация по id-шникам
__________________
Возможно сделать все. Вопрос времени |
|
12.10.2010, 13:35 | #10 |
Участник
|
Не будет? Т.е. таблица не загрузится? Или не будет, в смысле пересечения id не будет?
Мой опыт говорит о том, что при загрузке нового объекта без сохранения id, этому объекту будет присвоен следующий свободный в загружаемом диапазоне идентификатор. |
|
12.10.2010, 13:39 | #11 |
Administrator
|
Именно так и будет. Не будет пересечений. А id при загрузке на usp присвоится из того же загружаемого диапазона что и usr
__________________
Возможно сделать все. Вопрос времени |
|
12.10.2010, 13:40 | #12 |
Возьми свет!!!
|
Цитата:
Будет пересечение id да или нет?
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! |
|
12.10.2010, 13:42 | #13 |
Ищущий знания...
|
нет, пересечений не будет.
переносить надо будет без сохранения id.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
|
За это сообщение автора поблагодарили: Murlin (1). |
12.10.2010, 13:47 | #14 |
Возьми свет!!!
|
Спасибо всем большое.
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! |
|
12.10.2010, 18:46 | #15 |
Участник
|
Цитата:
Сообщение от Murlin
я решил включить разработку на usp слое для наших местных доработок
На сегодняшний день мы имеем готовый функционал на usr слое, который периодически должен будет обновляться, но заноситься он сравнением. Работая на usr слое мы переписываем написанный функционал и затираем его, кроме того имеем очень много функционала который нам пока не нужен или вообще не нужен. Не имея лучшего я предложил делать наши местные доработки на usp слое. |
|
12.10.2010, 19:34 | #16 |
Участник
|
Уже не раз обсуждали идеологию слоеных разработок.
С sukhanchik'ом имели опыт разных приложений с разными слоями, где шло обновление КАС слоя, как СП вниз под ЮСР с основным кодом. Одного слоя мне лично мало, но и использовать слои с одним полем нумерации - это не оч. хорошо. ЮСП занимать нельзя, он нужен для утилит (стираются слоем при нужде) и заливки ХРО сравнением без глюков (сравнение с ОЛД или при закачке не полноценное или глючит или нет удобный стрелочек). Поэтому в вашем случае стоит опустить весь ЮСР в КАС, а разработку билда вести на ЮСР, опуская в КАС после кодревью на сборке обновления. Но опять же, делать все это на рабочей базе тоже не хорошо, это удобно для Дев. Обновление слоем или ХРО тоже обсуждали. Важно не попасть на стриание таблиц при синхронизации. |
|
13.10.2010, 07:49 | #17 |
Возьми свет!!!
|
Цитата:
Сообщение от BOAL
Уже не раз обсуждали идеологию слоеных разработок.
С sukhanchik'ом имели опыт разных приложений с разными слоями, где шло обновление КАС слоя, как СП вниз под ЮСР с основным кодом. Одного слоя мне лично мало, но и использовать слои с одним полем нумерации - это не оч. хорошо. ЮСП занимать нельзя, он нужен для утилит (стираются слоем при нужде) и заливки ХРО сравнением без глюков (сравнение с ОЛД или при закачке не полноценное или глючит или нет удобный стрелочек). Поэтому в вашем случае стоит опустить весь ЮСР в КАС, а разработку билда вести на ЮСР, опуская в КАС после кодревью на сборке обновления. Но опять же, делать все это на рабочей базе тоже не хорошо, это удобно для Дев. Обновление слоем или ХРО тоже обсуждали. Важно не попасть на стриание таблиц при синхронизации. У нас нет ни кас ни вар никаких других кроме usr и usp. Притом при все что решение как бы на самом деле вертикальное, непонятно почему пожалели денег на слои.
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! Последний раз редактировалось Murlin; 13.10.2010 в 08:03. |
|
13.10.2010, 07:59 | #18 |
Возьми свет!!!
|
Цитата:
Сообщение от gl00mie
Так зачем же все-таки вам вести разработку на usp-слое? Какие проблемы вы хотите решить таким образом? Что сейчас мешает вести собственные доработки "сбоку" на том же usr-слое, где находится "пока" и "вообще" не нужный функционал? Если вы просто хотите иметь возможность вернуться к тому коду, который вы переписываете и затираете, то храните его в old-каталоге и все. Зачем придумывать себе лишние трудности, которые самим же потом придется преодолевать? Или, может, вы думаете, что за счет разработки на другом слое при "занесении изменений" на usr вам меньше придется потом сравнивать объекты и сливать изменения? Если так, то это заблуждение...
Хотя можно и проверить.
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! |
|
13.10.2010, 13:22 | #19 |
Участник
|
Murlin, ради бога, завязывайте, хватит уже. Вы какой-то фигней занимаетесь, и своим разработчикам гемор хотите устроить, и людей на форуме провоцируете на какие-то ненужные разборки, хоть бы прислушивались что вам объясняют, что ли.
Это сугубо личное мнение, я не могу вам запретить и дальше гнать волну.. |
|
13.10.2010, 15:46 | #20 |
Возьми свет!!!
|
Цитата:
Сообщение от Bober
Murlin, ради бога, завязывайте, хватит уже. Вы какой-то фигней занимаетесь, и своим разработчикам гемор хотите устроить, и людей на форуме провоцируете на какие-то ненужные разборки, хоть бы прислушивались что вам объясняют, что ли.
Это сугубо личное мнение, я не могу вам запретить и дальше гнать волну.. Нельзя ну нельзя, хорошо.... Таких нельзя еще миллион потому что кто то так сказал и захотел. Объясните почему нельзя. Id пересекаются - нет не пересекаются. usp глючит - неизвестно. занесение не работает как нужно - хорошо. В чем я собственное не прислушался? Какой геммор я собирался сделать для разработчиков? Упростить им сведение и разработку?
__________________
Axapta 3.0 sp 5 Oracle Я могу взорвать вам мозг!!! Последний раз редактировалось Murlin; 13.10.2010 в 16:00. |
|
Теги |
слои |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|