А давайте поговорим про CIL

[gl00mie]

Модели - механизм в определенном смысле более гранулярный, чем XPO-шники. В одной модели может быть один метод или табличное поле, в другой модели - другой метод или табличное поле. При выгрузке XPO весь объект попадает в выгрузку, максимум можно играться слоями. Это может сильно осложнить жизнь при слиянии изменений, если для одного и того же объекта часть изменений надо перенести, а часть - нет.
Кроме того, перенос проектами реально грозит разъехавшимися ID-шниками объектов, особенно тех, что в DataDictionary Одной из фишек 2012-й является вроде как преодоление проблемы ID-шников объектов - их пересечения и исчерпания. Частью решения стали ID-шники, специфичные для инсталляции, см. также The solution to the element ID problem, и при переносе модификаций проектами ID-шники не сохраняются - выделяются новые. Как минимум, это чревато невозможностью легко и просто перенести затем рабочую базу в тест, потому что в тесте будут совершенно другие ID-шники в SqlDictionary и в полях типа RefTableId. Сразу скажу, что модели тоже не решают эту проблему - надо переносить базу модели целиком.

[RVS]

Цитата:

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

Модели - механизм в определенном смысле более гранулярный, чем XPO-шники. В одной модели может быть один метод или табличное поле, в другой модели - другой метод или табличное поле. При выгрузке XPO весь объект попадает в выгрузку, максимум можно играться слоями. Это может сильно осложнить жизнь при слиянии изменений, если для одного и того же объекта часть изменений надо перенести, а часть - нет.
Кроме того, перенос проектами реально грозит разъехавшимися ID-шниками объектов, особенно тех, что в DataDictionary Одной из фишек 2012-й является вроде как преодоление проблемы ID-шников объектов - их пересечения и исчерпания. Частью решения стали ID-шники, специфичные для инсталляции, см. также The solution to the element ID problem, и при переносе модификаций проектами ID-шники не сохраняются - выделяются новые. Как минимум, это чревато невозможностью легко и просто перенести затем рабочую базу в тест, потому что в тесте будут совершенно другие ID-шники в SqlDictionary и в полях типа RefTableId. Сразу скажу, что модели тоже не решают эту проблему - надо переносить базу модели целиком.

Спасибо.. Дивно )) но..

- мне, как пользователю (а программист - это тоже.. гм.. пользователь).. нафиг не нужны все эти "красЯвости", с "бОльшими гранулярностями"..

Зачем это придумано - в общем, понятно.. да, и было - понятно.. ))

Остался вопрос : "- чем перенос проекта (а-ля "старая", до 2012, Акса) реально грозит.. переносящему?"

Собственно, все.. все прочее - маркетинг от Микрософта )

PS : "Одной из фишек 2012-й является вроде как преодоление проблемы ID-шников объектов - их пересечения и исчерпания. Частью решения стали ID-шники, специфичные для инсталляции, см. также The solution to the element ID problem, и при переносе модификаций проектами ID-шники не сохраняются - выделяются новые. Как минимум, это чревато невозможностью легко и просто перенести затем рабочую базу в тест, потому что в тесте будут совершенно другие ID-шники в SqlDictionary и в полях типа RefTableId."



Мне это напоминает.. Dimensions в 2012-й.. только ленивый, походу, на написал еще примочку, которая по имени и DefaultDimension вытаскивает значение + расшифровку )))

Уроды писали 2012. Чтоб им.. икалось ))

PS : вопрос - остался..

[belugin]

Цитата:

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

- мне, как пользователю (а программист - это тоже.. гм.. пользователь).. нафиг не нужны все эти "красЯвости", с "бОльшими гранулярностями"..

1. Больше "гранулярность" означает что больше ситуаций, когда вместо анализа исправлений можно просто перенести новый код. "Нафиг не нужны все эти "красЯвости", с "бОльшими гранулярностями"" означает "Я, как программист, люблю сидеть в утилите сравнения, анализировать, что изменилось и вручную сливать свои изменения с изменениями в новой версии" - но это свойство скорее новой версии AX, а не моделей, как таковых. Например, если вы сделали добавление кнопки на форме, безо всяких новых моделей, при накатывании изменений она также появится на измененной форме сама.
   
2. Модели так же получили неофициальное название "параллельные слои". Так как можно сделать несколько независимых моделей на одном слое. Теоретически можно совместить на одном слое два партнерских решения - правда это требует отказа от изменения кода - использования только точек расширения (события и т.д.).
   
3. Проекты Visual Studio, которые в AOT нельзя надежно перенести в каком-то виде, кроме как в модели. При экспорте в XPO может получится файл, который нельзя загрузить.

Моделям также присущи определенные недостатки:

• при импорте модели возникает проект обновления, предлагающий перекомпилировать все приложение (чего можно избежать, но все-таки)
  
• модели чрезвычайно чувствительны к номеру версии, на которых их делают. Часто, на более старую версию нельзя установить модель, сделанную на более новой версии.

Если работать с кодом только при помощи контроля версий, то можно совместить достоинства моделей с достоинствами XPO.

Добавил статью на erpkb - дополняйте

[Vadik]

Цитата:

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

Проекты Visual Studio, которые в AOT нельзя надежно перенести в каком-то виде, кроме как в модели. При экспорте в XPO может получится файл, который нельзя загрузить

C чего бы это вдруг ?

[belugin]

Цитата:

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

C чего бы это вдруг ?

Мне непонятен смысл вашего вопроса - вы говорите, что такого не бывает, или вам непонятны причины этого?

• Если первое, то попробуйте перенести через XPO проект отсюда http://axcoder.blogspot.ie/2014/11/s...sing-xlnt.html
  
• Если второе, то мне багу закрыли с формулировкой "юзайте модели"

[Vadik]

Первое. До сих пор не сталкивался. Попробую

[lvan]

Цитата:

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

Остался вопрос : "- чем перенос проекта (а-ля "старая", до 2012, Акса) реально грозит.. переносящему?"

смотря в каком ключе на вопрос посмотреть
если про "реальную" угрозу, то зависит от босса, IT админа (который бакапит базу), но в общем случае, думаю, вплоть до летального исхода.

[RVS]

Цитата:

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

смотря в каком ключе на вопрос посмотреть
если про "реальную" угрозу, то зависит от босса, IT админа (который бакапит базу), но в общем случае, думаю, вплоть до летального исхода.

Боюсь-боюсь-боюсь..

А на серьезе если - представьте, чисто умозрительно, что есть 2012-я, в которую новые доработки пытаются (и небезуспешно.. может быть - пока небезуспешно) переносить именно проектами.

Вопрос : чем это потенциально грозит. Ну, не переносящему, конечно, а самой Аксапте..

[RVS]

Цитата:

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

Как минимум, это чревато невозможностью легко и просто перенести затем рабочую базу в тест, потому что в тесте будут совершенно другие ID-шники в SqlDictionary и в полях типа RefTableId. Сразу скажу, что модели тоже не решают эту проблему - надо переносить базу модели целиком.

Как максимум - это решается ежедневным обновление Test <<-- Prod, со спасением проектов.. "кто не спрятался - никто не виноват".

У меня так вот сейчас пока.. Вооот.. ))

ЗЫ : "Мелочь" а-ля что-то там поправить или отчет нарисовать - "разрабатывается" на Test. Отсюда и приколы типа "не уходи с работы, пока не спас проект.. в папку, блин.."

Повторяю : архитектура сделана.. уродами, и плохо документирована. Почему плохо - а потому, что они сами не знают, ЧТО из этого.. вырастет ))