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

[twilight]

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

[CDR]

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

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

Например:

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

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

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

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

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

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

[EVGL]

Цитата:

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

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

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

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

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

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

и.т.п.

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

[Ivanhoe]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[EVGL]

Цитата:

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

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

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

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

[CDR]

Цитата:

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

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

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

Цитата:

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

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

А чего кнопки стоят? Картинку приделать? Так я сейчас наоборот получаю эстетическое удовольствие от этого. В ListPage так же не вижу ничего сложного - квери, простой класс и элементарная форма. Зато получается единый интерфейс.

Цитата:

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

У всех уважаемых разработчиков давно есть свое семейство классов для таких отчетов.

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

Цитата:

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

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

Для многих вообще в чем-либо разбираться - это очень-очень сложно.

Цитата:

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

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

Везде, где используются поля "Дата С" и/или "Дата По". Это различные ставки, курсы, цены, прайсы, планы, прогнозы и т.п.

Цитата:

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

А разобраться с ОСВ и понять почему она тормозит?

Разобраться с ОСВ (особенно модульными) и в предыдущих версиях было тем еще челенджем.

Цитата:

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

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

Ну так в итоге стало сложнее в 1,5-2 раза? или на 20%?

[trud]

Цитата:

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

Везде, где используются поля "Дата С" и/или "Дата По". Это различные ставки, курсы, цены, прайсы, планы, прогнозы и т.п.

вот это все же на мой взгляд немного не верное понимание технологии. это нужно когда сущность может меняться с течением времени, при этом это одна и та-же сущность - например фамилия одного человека. план на январь и план на февраль - это 2 совершенно разные сущности, реализовать это с помощью dateEffective не очень правильно. Т.е. реальное то применение все же крайне ограниченно

[CDR]

Цитата:

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

вот это все же на мой взгляд немного не верное понимание технологии. это нужно когда сущность может меняться с течением времени, при этом это одна и та-же сущность - например фамилия одного человека. план на январь и план на февраль - это 2 совершенно разные сущности, реализовать это с помощью dateEffective не очень правильно. Т.е. реальное то применение все же крайне ограниченно

Какое тонкое понимание технологии, снимаю шляпу.

А если серьезно, то я имел ввиду реализацию какого-либо планового/прогнозного показателя внутри одного плана.

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

А вообще в AX, как и в любой другой системе, есть объекты, а есть их характеристики. Так вот как только возникает практическая задача хранить изменения какой-либо характеристики во времени (а такие задачи возникают довольно регулярно), то сразу же можно использовать Date-Effective таблицы.

Но это сложно.
Значительно проще по старинке закодировать обычные таблицы историй, значений и пачку методов типа findCurrent(), findOnDate() и т.п.

[gl00mie]

Подниму еще раз тему.

Цитата:

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

Сложнее стала система (больше элементов). И бюджеты растут, и требования. Все сложнее. Просто нужно это принять.

С этой точки зрения кажется интересным обсуждение конца 2010-го года В какой системе быстрее вести разработку? AX или NAV:

Цитата:

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

Определение: "быстрее вести разработку" значит добиваться заранее определенных результатов посредством программирования за меньшее время.
Ответ: быстрее вести разработку в той системе, где связей меньше.
Пояснение: "скорость разработки" зависит не от удобств самой системы, а от количества объектов, которые затрагиваются (прямо или косвенно) данной разработкой.
Следствие: Чем более функционально развитая система, тем больше вероятность зацепить большое количество системных объектов. Тем больше вероятность "медленной" разработки.

Возможно, этим и объясняется увеличение времени на разработку:

Цитата:

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

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

[belugin]

Количество связей зависит так же от качества проектирования (вспомним всякие Law of Demeter).

Также обычно интересуют связи в какой-то выделенной области.
К сожалению, среда X++ не поддерживает разбиение кода на Namespaces/Packages то есть размер областей, на которые можно формально разбить довольно велик + даже, если такое будет сделано, само по себе приложение не разбито на куски с контролируемыми связями и разбиение будет трудоемко.

Еще часть абстракций в 2012 довольно "дырявые" например, для работы с LedgerDimension необходимо знать их внутреннюю структуру + не поддерживается польностью MorphX на уровне остальных типов данных (кроме бросания поля на форму надо еще создавать спецобъекты для управления контролом).