А что такого принципиального в 2012? По моему хороший разработчик без труда в ней разберется

[twilight]

***Тема выделена из Состояние рынка труда разработчик Axapta, Москва //oip ***

Цитата:

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

P.S. надо бы изучать 2012, я, например, без хоть какого-то опыта в 2012 сейчас не рассматриваю в штат.

А что такого принципиального в 2012? По моему хороший разработчик без труда в ней разберется.

[Ivanhoe]

Вот только первый проект на AX 2012 разработчик делает в 1,5-2 раза дольше. Ну и с оценками промахивается. Можем в отдельной теме обсудить

[Pustik]

С точки зрения разработчика, не вижу проблем работы для кандидата, знающего и имеющего опыт работы в АХ в предыдущей версии. С точки зрения консультанта, возможно, что это не так. Но давайте подумаем, насколько консультант, знающий АХ2009, отличается от себя самого "якобы" знающего АХ2012. И теперь также, только для разработчика?

[gl00mie]

Цитата:

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

С точки зрения разработчика, не вижу проблем работы для кандидата, знающего и имеющего опыт работы в АХ в предыдущей версии.

- стоит задача при разноске банковской выписки тянуть определенную фин.аналитику для банковского счета из счета контрагента.
- а, ну это я щас подтяну Dimension[4]. Ой, а где всё?..
- стоит задача создать артефакты контроля доступа для метода сервиса, вызываемого через SysOperation framework.
- а, ну это я щас SecurityKey повешу на пункт меню. Ой, а где всё?
- стоит задача добавить новый класс-наследник в иерархию классов, использующую SysExtension framework.
- а, ну это я щас пару строк кода в switch добавлю для своего наследника. Ой, а где ж оно? Что еще за атрибуты?..
- стоит задача доработать интеграцию стороннего приложения с Аксаптой.
- сейчас быстренько дернем .NET Business Connector. Ой, приложение не в том же домене работает? Какие-такие веб-сервисы?..
- стоит задача сделать импорт продуктов из Excel-файла.
- это импорт номенклатуры что ли? так у меня уже готовый код есть, с проекта на проект таскаю. Ой, а чего за EcoRes*-таблицы? А как мне теперь добавить значение аналитики "размер"?..
- стоит задача доработать кастомизацию, отрабатывающую на validateWrite() такой-то стандартной таблицы.
- ну это как два пальца... ой, тут ведь только sys-слой, а где же код кастомизации-то? какие-такие pre-/post-обработчики событий?..
- стоит задача реализовать обобщенный код, который в зависимости от типа переданного табличного буфера...
- как нечего делать. Ой, а разве buffer.tableId не определяет однозначно таблицу? Что еще за InstanceRelationType?..
- стоит задача реализовать lookup-форму с парой закладок.
- это вообще детский сад. Ой, а что это за ReferenceGroup такой? И почему моя lookup-форма вместо исходной записи, на поле которой вызывается, получает в аргументах запись моего же справочника, который я показываю в lookup'е?
- стоит задача разобраться, почему интерактивно периодическая операция отрабатывает нормально, а в пакете - валится.
- этим нас не напугаешь, щас вот в консоли пакетного сервера аксаптовый отладчик запущу, включу глобальные точки останова... Ой, какой-такой CIL?..
- etc.

[Logger]

Спасибо за сравнение.
Интересно было бы теперь сравнить что стало проще и быстрее для разработки а что медленнее и сложнее (читай - дороже).

[Ivanhoe]

Просьба к модераторам выделить обсуждение разработки 2012 в отдельную ветку. Там и продолжим

[oip]

Выделил в отдельную тему. Ну и заодно напомню свою прошлогоднюю запись.
axforum blogs: Небольшой опыт перевода собственного модуля AX 4.0 -> AX 2009 -> AX 2012R2

Цитата:

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

Интересно было бы теперь сравнить что стало проще и быстрее для разработки

Краткий ответ: ничего. Разве что какие-то мелочи, но на общем фоне это несущественно.

[EVGL]

Цитата:

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

Спасибо за сравнение.
Интересно было бы теперь сравнить что стало проще и быстрее для разработки а что медленнее и сложнее (читай - дороже).

Легко: дороже стало, а чтобы проще и быстрее - нет, такого не припомню.
Я бы теперь смело умножал затраты на разработку и настройку на 1,5 - 2.

[Ivanhoe]

Добавлю еще про отчетность - Reporting services конкретно другой зверь. Про разработку для POS я вообще молчу.

[twilight]

В OLAP стало проще работать с датой, так как теперь Аксапта генерит собственные таблицы для дат (раньше использовалось стандартное измерение времени в OLAP), которые можно модифицировать как угодно по своему усмотрению.

[CDR]

По-моему, происходит некоторая подмена понятий.

В категорию "сложно" автоматом записали все, что стало "по-другому". А это далеко не одно и тоже. Имхо, очень многие вещи стали действительно проще, но "по-другому".

Например:

Использование шаблонов форм, создание типичных форм сейчас стало проще и быстрее.

Использовать SysOperation, как оказалось, действительно проще и быстрее, чем RunBase. Особенно, добавив несколько своих атрибутов для стандартных задач (например, SysOperationControlAllowEditAttribute)

Написание excel-отчетов используя XmlExcelReport_RU стало в разы проще и быстрее.

Создание Date-Effective таблиц стало проще и быстрее.

Архитектура финансовых аналитик стала сложнее, но для 90% практических задач трудоемкость практически не изменилась. А если взять довольно часто встречающуюся задачу отражения какого-либо справочника системы в фин. аналитику, то сделать это стало значительно проще и быстрее.

В общем, да, очень много стало по-другому. Но это != сложно.

[EVGL]

Цитата:

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

Использование шаблонов форм, создание типичных форм сейчас стало проще и быстрее.

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

Цитата:

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

Использовать SysOperation, как оказалось, действительно проще и быстрее, чем RunBase. Особенно, добавив несколько своих атрибутов для стандартных задач (например, SysOperationControlAllowEditAttribute)

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

[belugin]

Цитата:

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

надо писать три класса вместо одного.

От двух (контракт, действие) до четырех (контракт, контроллер, действие, UI builder).
А почему трудоёмчее написать три класса, чем один в котором все вперемешку?

[Ivanhoe]

Цитата:

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

По-моему, происходит некоторая подмена понятий.

В категорию "сложно" автоматом записали все, что стало "по-другому". А это далеко не одно и тоже. Имхо, очень многие вещи стали действительно проще, но "по-другому".

Слово "проще" появилось не с самого начала. Изначально тема возникла из моего видения, что разработчик в AX 2012 потратит больше времени на аналогичную задачу. При этом я могу судить по десяткам разработчиков и десятку проектов, к которым я имею непосредственное отношение.

Цитата:

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

Использование шаблонов форм, создание типичных форм сейчас стало проще и быстрее.

Не соглашусь. Одни кнопки чего стоят. А если делать "красивые" формы как в стандарте (ListPage), то это намного больше времени. И дело не в программисте, технологии или еще чем - просто в AX 2012 теперь так.

Цитата:

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

Написание excel-отчетов используя XmlExcelReport_RU стало в разы проще и быстрее.

У всех уважаемых разработчиков давно есть свое семейство классов для таких отчетов. Но, это локализация. А все остальные репорты в RS - с ним разбираться с нуля очень сложно, для многих очень-очень сложно.

Цитата:

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

Создание Date-Effective таблиц стало проще и быстрее.

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

Цитата:

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

Архитектура финансовых аналитик стала сложнее, но для 90% практических задач трудоемкость практически не изменилась. А если взять довольно часто встречающуюся задачу отражения какого-либо справочника системы в фин. аналитику, то сделать это стало значительно проще и быстрее.

Вы уверены? А удаления, апдейты? А просто тестовые данные почистить? А разобраться с ОСВ и понять почему она тормозит? А куча таблиц и вьюх, по которым можно просто историю развития вопроса изучать. Сделали сначала "красиво", а потом - начали костыли расставлять по всей системе, ибо не работало.

Еще раз сформулирую свою мысль. Аналогичный проект AX 2012 первый раз разработчик делает в 1,5 - 2 раза дольше. Второй и дальше - дольше процентов на 20%. По консам похожие цифры.

[Logger]

Цитата:

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

От двух (контракт, действие) до четырех (контракт, контроллер, действие, UI builder).
А почему трудоёмчее написать три класса, чем один в котором все вперемешку?

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

[belugin]

Цитата:

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

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

По-моему, когда разложено по полочкам, вникать в чем смысл проще: в контракте и UI builder не будешь искать бизнес логику. понятно какие переменные используются как параметры, а какие только во время выполнения для временных надобностей.

[EVGL]

Цитата:

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

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

Недавно делал демо, в котором Blocked для номенклатуры ставился "передним числом", своего рода Product Lifecycle для бедных. Сделал вместо поля таблицу, добавил effectivity и понял, что чудес не бывает: для конкретной задачи все равно пришлось писать код и насиловать интерфейс.

Но, как минимум, теперь есть шаблон для подобных разработок, что хорошо.

[Logger]

Цитата:

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

По-моему, когда разложено по полочкам, вникать в чем смысл проще: в контракте и UI builder не будешь искать бизнес логику. понятно какие переменные используются как параметры, а какие только во время выполнения для временных надобностей.

Да это так. Но это не противоречит тому что я сказал.

А что в runBase разве не разложено по полочкам ?
Нужен интерфейс ?
Сразу смотришь методы dialog getFromDialog и.т.п.

Нужна логика работы ?
Смотришь run

и.т.п.

Какая разница как методы разбросаны по классам ?

[EVGL]

Да ладно вам, все это банальности - RunBase, SysOp... Дополнительное value для клиента стремится к нулю, ему это все до фонаря, трудозатраты примерно одинаковые, только для SysOp-ов больше вероятность ошибки на копипасте.

[belugin]

Цитата:

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

Какая разница как методы разбросаны по классам ?

Это все справедливо если в классе нет никаких переменных и методов кроме перечисленных. Если они появляются, уже не решишь. Например метод convertItem может использоваться как для чего-то внутри run так и для целей UI. По полю не сразу тоже определишь, для чего оно используется - является параметром? результатом работы, какой-то временный кеш?