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

[S.Kuskov]

Приведите пример конкретной ситуации в которой разработка на другом слое оказывается полезной. Примерно в таком формате: делаем на отдельном слое так и так - в результате легко получаем то-то и то-то, а вот если бы мы тоже самое делали бы не на отдельном слое, а на том же самом, то то-то и то-то получить было бы сложнее.

А то на самом деле многие просто не понимают ради чего вы всё это затеиваете

[Bober]

Ноу проблем. Звиняйте если шо. Ваше дело, делайте как знаете...

[BOAL]

Цитата:

Сообщение от S.Kuskov

Приведите пример конкретной ситуации в которой разработка на другом слое оказывается полезной. Примерно в таком формате: делаем на отдельном слое так и так - в результате легко получаем то-то и то-то, а вот если бы мы тоже самое делали бы не на отдельном слое, а на том же самом, то то-то и то-то получить было бы сложнее.

А то на самом деле многие просто не понимают ради чего вы всё это затеиваете

Есть обновляемый (регулярно) код рабочего приложения или нескольких (у клиентов один базовый стартап проекта). Есть множество разработчиков (пусть даже 2, тк когда 1, то это ты и есть, и проблем нет, все помнишь).
Разработка идет в пустом слое, проходи время, получаем простую дельту сбором проекта по слою (а у всех всегда разработчики все правки делали в проектах или были случаи забывания очень важной строчки. поправленной походя?)
Изучаем эту дельту простым сравнением слоев или даже так, на глазок, что там вообще менялось. Выгружаем в ХРО, опускаем на слой билда. Получаем .aod файлик по сути СервисПак.
Если у клиента были свои правки, то они их сами могут поднять на такой вот сервис пак....

Да и чего это я все описываю? Пример? А обновление самих СервисПаков почему идет слоями? Был бы один слой и всех дел, как в 1С слияние конфигураций и всем счастье, ан нет, АХ идет в куче слоев.

Второй полезный метод слоев - это разделение на базовый функционал по модулям. То есть, есть АХ "решение" и накрутка его под проект. При этом следующий проект стартует не с 2х недель на очистку версии от мусора (ненужного клиенту) или не помоечная версия в итоге (после 2-3 проектов).

В общем, слои - это отличный инструмент, которым можно и не пользоваться. Возможность подкладки их в виде файлов - конкурентное преимущество над другими системами, где этого нет, которое будет возможно убито в АХ6 убиранием такой опции (весь код в БД). Просто даже сами разработчики в МС уже не понимают этого, вот им это и не нужно, пришли новые ребята и давай кодить, устраняя "фатальный недостаток" дамгардовской еще архитектуры АХ. Это и ясно, есть два уровня приближенности к практическому использованию - внедренцы (и конечные клиенты) и вендоры.
Скорость разработки, поддержки, обновления сложноизменненнго приложения - вот текущие преимущества платформы. Жаль на фоне новых фич терять старые. Эволюция, однако.

[S.Kuskov]

+1.
Все преимущества разработки на разных слоях становятся очивидными, если в процессе разработки появляется потребность в совмещении нескольких приложений. Но топикастер, как мне кажется, поднял этот вопрос немного в другом контексте:

Цитата:

Сообщение от Murlin

Дело в том что я решил включить разработку на usp слое для наших местных доработок ...

[Murlin]

Цитата:

Сообщение от S.Kuskov

+1.
Все преимущества разработки на разных слоях становятся очивидными, если в процессе разработки появляется потребность в совмещении нескольких приложений. Но топикастер, как мне кажется, поднял этот вопрос немного в другом контексте:

Мы имеем приложение московское которое дописываем и переписываем под наши собственные нужды. Разве не тоже самое как и вообще обычная разработка на любом слое??? Копирование это приложение произошло в апреле месяце последний раз если не раньше, есть функционал в московском приложении которого нет в нашем, но мы дописали и свой и переписали имеющийся. Я пробовал занести функционал, которого мы не имеем. Но я найти то чего у нас нет не могу за ограниченное время!!! Потому что один проект завязан на другой. Если бы это все делалось как положено в отдельном слое, а филиалам отдавали usr слой то проблем было бы меньше. А теперь чтобы занести все это я должен сравнить наш usr с московским при том при всем что наш usr слой уже изменен значительно.
Что это как не разные приложения?
Что дает случай если usp работал бы нормально
Первое как я рисую себе схему, возможно я ошибаюсь:
Мы копируем функционал usr слоя москвы на чистое приложение.
Сравниваем с более низкими слоями.
Создаем проект, заносим его на нашу базу в usr слой, отсутствующим объектам назначаются новые а не существующие идентификаторы. То чего у нас не было будет лежать на usr. А то что было изменено сразу же видим. Сравниваем usp И usr и заносим изменения с учетом наших.
Но к сожалению я тоже уже думаю что теперь будет очень много проблем, так как разработка длительное время велась на usr.

[Михаил Андреев]

Возможно, я неправ. А почему "московское приложение" не использует нижние слои, например, CUS (если приложение разрабатывает клиент) или VAR (если приложение разрабатывает партнёр)? Тогда "филиал" сможет вести свою разработку на USR и слой USP останется для экстренных случаев.

[Murlin]

Цитата:

Сообщение от Михаил Андреев

Возможно, я неправ. А почему "московское приложение" не использует нижние слои, например, CUS (если приложение разрабатывает клиент) или VAR (если приложение разрабатывает партнёр)? Тогда "филиал" сможет вести свою разработку на USR и слой USP останется для экстренных случаев.

Я не знаю почему... Писали под себя и это видно а теперь все это у нас.

[S.Kuskov]

Цитата:

Сообщение от Murlin

Что это как не разные приложения?

Действительно, они и есть. Теперь я понял вашу проблему. Но решал бы я её всё-таки немного по другому. Для совмещения двух приложений действительно логично иметь два слоя. Но внимание использование одновременно двух слоёв оправдано только в момент установки обновления. Т.е. я бы собственную разработку продолжал бы вести в usr, а для заливки обновления временно пользовался бы usp.

Ещё уточняющий вопрос. Обновления базового приложения из центра к вам поступают в виде xpo или в виде слоя?

[Murlin]

Цитата:

Сообщение от S.Kuskov

Действительно, они и есть. Теперь я понял вашу проблему. Но решал бы я её всё-таки немного по другому. Для совмещения двух приложений действительно логично иметь два слоя. Но внимание использование одновременно двух слоёв оправдано только в момент установки обновления. Т.е. я бы собственную разработку продолжал бы вести в usr, а для заливки обновления временно пользовался бы usp.

Ещё уточняющий вопрос. Обновления базового приложения из центра к вам поступают в виде xpo или в виде слоя?

Нам ничего не поступает, имеем доступ копируем usr, сравниваем, создаем xpo, и заливаем сравнением. Но оно очень сильно глючит, не появляются стрелочки и тд.Вот настолько я все это понял. Но сравнением делать все сложно т.к. иногда я грешу кто то еще грешит не оставляя комментариев в коде. Нужно быстро исправить, нашел ошибку на живом приложении и тд которую не заметили при тестировании. Или те же отчеты и формы, там вообще не поймешь кто и зачем добавлял. Какое поле удалили какое добавили, где, кто, для чего и почему.

[S.Kuskov]

Цитата:

Сообщение от Murlin

Но сравнением делать все сложно ...

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

Ещё раз напомню про каталог OLD. Продумайте альтернативные варианты.

[Murlin]

Цитата:

Сообщение от S.Kuskov

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

Ещё раз напомню про каталог OLD. Продумайте альтернативные варианты.

Спасибо всем.
Думаю что тема закрыта.