Минимальный набор разработчика?

[Андре]

Цитата:

Есть непонимание работы данного механизма.

Может быть.

Цитата:

Какая разница сколько слоев, если запустится из всех одноименных элементов только один из самого "внешнего" слоя (системный - ядро)?

Удобнее каждому программисту работать в своем слое. Особенно если работают не на одном приложении. В этом случае слияние происходит намного проще. 2 программиста - 2 слоя. 3 программиста - облом.

[komar]

??? И что они будут делать на такой куче слоев? 1 для финальной версии, 1 для разработки.
А если каждому свой слой, это как какждому футболисту свой мяч. Кто-то, кто сидит на USR забьет все модификации остальных.

[Андре]

Цитата:

как какждому футболисту свой мяч

ОК. Подумаю.

[mazzy]

хм...
Павел, там не 6 слоев, а больше.
Всем, ну прочтите, наконец, документацию.

[Pavel]

Цитата:

Изначально опубликовано mazzy
хм...
Павел, там не 6 слоев, а больше.
Всем, ну прочтите, наконец, документацию.

погорячился
правильный ответ - восемь

[dmit2604]

Разные слои действительно удобно использовать для коллективной работы, когда хочется каким-то образом "фиксировать этапы разработки" - т.е получать некоторые промежуточные версии. Кроме того, уже написанная и перенесенная на более высокий слой функциональность без особых опасений может быть модифицируема конечным пользователем - всегда можно быстро "грохнуть" axusr.aod и нет проблем.

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

Технология слоев, на самом деле - ураган! Как бы наши локализаторы работали, не будь у них своего слоя? Как бы ты смог посмотреть в спину удаляющейся международной функциональности? Грохнул GLS слой - и нет у тебя CRM например. Удобная вещь, что ни говори! Удалил Dis и радуешься западному учету... Все конечно не так просто, но мысль, я думаю, ясна.

[Pavel]

Цитата:

Изначально опубликовано dmit2604
Еще круче, если вы напишете функциональность для какой-нибудь газо-шерсте-бумажной промышленности и захотите его продавать, да так, чтобы не порушить клиентской USR функциональности. И права свои сохранить. Тогда вся ваша функциональность вполне может разместиться на одном слое, к которому ни у кого более не будет ключей. Поставьте всюду свои копирайты в тексте и радуйтесь

Все это конечно прекрасно, но когда придет время установить новую версию, сервис пак и т.п., то все станет "грустно". Потому что самая сложная задача - синхронизация результатов разработок "разных сторон".

[mazzy]

оооо.
Павел, читайте документацию.
В частности, раздел Navision Axapta Design Guidelines for cost efficient upgrades.

И перестаньте, пожалуйста, нести чушь.

[dmit2604]

2 Pavel:

Цитата:

..когда придет время установить новую версию, сервис пак и т.п., то все станет "грустно"

А это всегда не простая задача. Есть некоторые секреты, как минимизировать головную боль при обновлении. Вряд ли в скором времени переименуют LedgerTable или пару Voucher-TransDate.
Хотя имея ввиду то, что русская функциональность то и дело радует нас таблицами с префиксом DEL , следует писать

Цитата:

if (RCash) or (Cash_Ru) or (Rcash_DEL) or (DEL_Rcash)
....

Прискорбно, но Вы правы, Павел. Наверное на западе это звучало бы убедительнее...

[Pavel]

Цитата:

Изначально опубликовано mazzy
оооо.
Павел, читайте документацию.
В частности, раздел Navision Axapta Design Guidelines for cost efficient upgrades.
И перестаньте, пожалуйста, нести чушь.

2mazzy Не отвлекайся от чтения документации и не трать попусту свое и чужое время, если не в состоянии написать что-то по существу

Проблема разработчика, создавшего свое решение, будет состоят в том, чтобы поддерживать его актуальность в новых международных и российских версиях. Данная задача может не решаться путем механического переноса программного кода и требовать модификации бизнес логики решения.
Механизм слоев никаким образом не влияет на возможность «сосуществования» бизнес логик решений разных разработчиков.

[dmit2604]

Цитата:

Изначально опубликовано Mazzy
И перестаньте, пожалуйста, нести чушь

Не вижу смысла продолжать дискуссию.