Microsoft Dynamics AX 2012 White Paper: Introduction to the SysOperation Framework

[Vadik]

Overview
The SysOperation framework enables application logic to be written in a way that supports running interactively or via the batch server in Microsoft Dynamics AX 2012. This white paper illustrates how the SysOperation framework can be used to build operations that can run asynchronously and make use of the full processing power available on the server. Four code samples are presented and explained to illustrate the comparison between the SysOperation and the RunBaseBatch framework, and to demonstrate the use of the SysOperation framework in building asynchrouous and scalable operations.
Microsoft Dynamics AX 2012 White Paper: Introduction to the SysOperation Framework

[mazzy]

ну, нафига? нафига?! они используют вызов метода через classstr()/methodstr().
так же перестают работать перекрестные ссылки, синтаксическое переименование. начинаются глюки при переименовании метода.

пидарасы. нет у меня другого слова.

[Vadik]

Цитата:

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

ну, нафига? нафига?! они используют вызов метода через classstr()/methodstr().
так же перестают работать перекрестные ссылки, синтаксическое переименование. начинаются глюки при переименовании метода.
..
нет у меня другого слова.

В целом согласен но хотел бы уточнить некоторые детали.. О какой версии речь? В 4.0 и 2012 к примеру перекрестные ссылки на staticmethodstr() и classstr() создаются.

[mazzy]

Цитата:

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

В целом согласен но хотел бы уточнить некоторые детали.. О какой версии речь? В 4.0 и 2012 к примеру перекрестные ссылки на staticmethodstr() и classstr() создаются.

я не про staticmethodstr
я про invokeStaticMethodIL, который выполняется в дальнейшем.

во-первых, они ВЫНУЖДЕНЫ делать assert для invoke.
во-вторых, invoke уже не ловится перекрестными ссылками. И встав мышкой на метод контролера мы НЕ узнаем, где же он вызывается. Нужен дополнительный и трудоемкий анализ.

[sukhanchik]

Цитата:

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

ну, нафига? нафига?! они используют вызов метода через classstr()/methodstr().

Не... теперь надо не так говорить. Надо говорить так: "О! Они теперь пишут названия методов не строкой в кавычках, а используют встроенные функции classstr()/methodstr(). Гениально!".
Лояльнее надо быть к вендору . И во всем искать свою плюсы. Даже на кладбище

Я так понимаю, что речь идет о попытке переноса кода в СIL. Отсюда и вызов метода. Или я чего-то не понял? (Тоже неоднократно перечитал доку).
Т.е. как я понял изначально - ключевое отличие SysOperationFramework от RunBaseBatch состоит в том, что первый предполагает вызов кода из CIL. А во всем остальном (с т.з. идеологии) никаких изменений нет. Я неправ?

[mazzy]

Цитата:

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

ключевое отличие SysOperationFramework от RunBaseBatch состоит в том, что первый предполагает вызов кода из CIL.

Не-а.
см. страница 8 - метод runbase.run
и на странице 13 результат выполнения runbase на CIL

[mazzy]

может я чего не понимаю?
может, кто-нибудь сможет объяснить: "ЗАЧЕМ они делают это?"

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


может, кто-нибудь может придумать "ПОЧЕМУ человек-программист захочет использовать ЭТОТ фреймворк? в каких сценариях?"

вот, например, runbasebatch имеет очень понятное, простое и человеческое объяснение: разгрузить компьютер пользователя и перенести тяжелую обработку на мощный сервер.
есть более программистское (но все еще понятное) расширение этого объяснения: Заодно и параметры повторения есть, и задачи выполняются поочередно (что снижает вероятность блокировок).

А для этого Фреймворка есть какое-нибудь объяснение на человеческом языке: ЗАЧЕМ?

весь документ я прочитал. introduction перечитал несколько раз.
все равно - нуб и опозорился.

[trud]

Ну по моему все более понятно.
Назначили нового Архитектора с 20 летним ERP опытом, который слова ранбейсбетч и перекрестные ссылки и не слышал ранее
А тут все так красиво - разделение кода и данных, попробуй возрази

[belugin]

для добавления одного параметра в RunBase надо:

- добавить поле в класс
- добавить поле в макрос со списком полей для упаковки/распаковки
- по хорошему еще:
1. добавить два макроса для новой версии в classdeclaration
2. Добавить в распаковку логику по разделению этих версий
- добавить в создание диалога
- добавить в получение данных из диалога

Для добавления параметра в SysOperationFramework надо

- добавить поле в класс-контракт
- добавить метод-свойство в класс-контракт
- аннотировать метод атрибутами для диалога

[mazzy]

Цитата:

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

Для добавления параметра в SysOperationFramework надо

- добавить поле в класс-контракт
- добавить метод-свойство в класс-контракт
- аннотировать метод атрибутами для диалога

О! и поэтому программист теперь должен работать не с одним классом, в котором присутствуют все переменные, а с целым набором классов, в котором все равно будут эти же переменные (но разбросанные по коду)? и к тому же через assert/invoke и methodstr?

Максим, а почему это проще/предпочтительнее для разработчика? Может быть я чего не знаю?

Можно я повторю вопрос: "кто-нибудь может придумать "ПОЧЕМУ человек-программист захочет использовать ЭТОТ фреймворк? в каких сценариях?"

[DSPIC]

Цитата:

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

О! и поэтому программист теперь должен работать не с одним классом, в котором присутствуют все переменные, а с целым набором классов, в котором все равно будут эти же переменные (но разбросанные по коду)? и к тому же через assert/invoke и methodstr?

Максим, а почему это проще/предпочтительнее для разработчика? Может быть я чего не знаю?

Можно я повторю вопрос: "кто-нибудь может придумать "ПОЧЕМУ человек-программист захочет использовать ЭТОТ фреймворк? в каких сценариях?"

Цитата:

Routing tasks to the .NET Common Language Runtime (CLR) environment.

- это главная фича сего вреймфорка. Ради этого он был создан. На практике это пока ничего не даёт, но возможно это промежуточный шаг в сторону полного отказа от X++.

Цитата:

может, кто-нибудь может придумать "ПОЧЕМУ человек-программист захочет использовать ЭТОТ фреймворк? в каких сценариях?"

Предполагаю два сцерия: когда использование этого чуда станет обязательным для ISV или же RunBase класс уберут из системы в след. версии.

[mazzy]

Цитата:

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

Цитата:

Routing tasks to the .NET Common Language Runtime (CLR) environment.

- это главная фича сего вреймфорка.

Предполагаю два сцерия: когда использование этого чуда станет обязательным для ISV или же RunBase класс уберут из системы в след. версии.

может быть, может быть... надо подумать.

[belugin]

Цитата:

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

О! и поэтому программист теперь должен работать не с одним классом, в котором присутствуют все переменные, а с целым набором классов, в котором все равно будут эти же переменные (но разбросанные по коду)?

Эти переменные будут только в одном месте - в контракте.
Зато
- не будет переменных и кода, который генерирует интерфейс
- не будет макросов и кода для упаковки распаковки

Цитата:

и к тому же через assert/invoke и methodstr?

можешь привести пример с исследованием кода который вызвал вопросы?

Цитата:

Максим, а почему это проще/предпочтительнее для разработчика? Может быть я чего не знаю?

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

Цитата:

Можно я повторю вопрос: "кто-нибудь может придумать "ПОЧЕМУ человек-программист захочет использовать ЭТОТ фреймворк? в каких сценариях?"

- например, программист не любит писать 100 раз одно и то же
- программист хочет ускорить работу за счет удобного распараллеливания

[mazzy]

Цитата:

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

Эти переменные будут только в одном месте - в контракте.

Анекдот:
- Внученька, у меня в молодости была только одна любовь: морячки.

Максим, ты заметил, что в утверждении смешал множественное и единственное число?
Если переменные (множ. число) будут в (одном) контракте, то это ничем не отличается от существующего подхода.
Если каждая переменная (ед.число) будет в своем контракте, то никак нельзя сказать, что переменные в одном месте - они в разных контрактах

Ну, Максим... Ну, елы-палы.

Цитата:

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

- не будет переменных и кода, который генерирует интерфейс

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

Цитата:

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

- не будет макросов и кода для упаковки распаковки

Именно ради этого все и затевалось?

Цитата:

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

можешь привести пример с исследованием кода который вызвал вопросы?

О! Ты ведешь себя как 1Сники в дискуссиях.
Во-первых, чего ты на меня то стрелки переводишь?
Во-вторых, а чего ты тему меняешь? Мы говорим о Фреймворке.

Я конечно отвечу. Но предупреждаю сразу: категорически отказываюсь обсуждать "проблемы исследования кода" в этой ветке.
Примеры:
* отчеты, основанные на runbaseReport
* идиотские invoke-вызовы в русском модуле "Налоговый учет"
* кретинские invoke-вызовы в русском модуле "Расчеты с персоналом"
* масса invoke-вызовов в ax2012. конкретных примеров уже не помню. знаю только, что постоянно спотыкаюсь.

Примеры, где invoke-вызовы оправданы:
* модуль "конфигуратор продукции"

пожалуйста, давай в этой ветке обсуждать Framework.
если хочешь обсуждать "проблемы с invoke-вызовами" открывай новую ветку.

[belugin]

Цитата:

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

Анекдот:
- Внученька, у меня в молодости была только одна любовь: морячки.

Максим, ты заметил, что в утверждении смешал множественное и единственное число?
Если переменные (множ. число) будут в (одном) контракте, то это ничем не отличается от существующего подхода.

Именно. Я про это и говорил, что все параметры в одном месте.

Цитата:

почему программист почувствует себя счастливым от этого?

Code is our enemy

Отсутствующий код не надо читать, не надо разрабатывать, не надо апгрейдить на следующие версии/севиспаки (кстати, сравни сколько надо мерджить в ранбейз по сравнению с SysOperationFramework - фактически только декларацию одной переменной на параметр - метод со всеми причиндалами сам смёрджится за счет слоев).

Нельзя забыть добавить переменную в список созраненных.
Нельзя случайно написать другой тип у DialogField чем у переменной.

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

Цитата:

автогенерация интерфейсов подходит только для тривиальных случаев.

ИМХО большая часть автоматизации - это освобождение человека от тривиальных случаев и болшая часть случаев - трививальна

Цитата:

С которыми замечательно справляется и runbase

Ранбейз гененрацию интерфейса перекладывает на авторов конкретных операций.

Цитата:

Именно ради этого все и затевалось?

Это я не знаю - надо посмотреть спеки. Я говорю о тех достоинствах

Цитата:

О! Ты ведешь себя как 1Сники в дискуссиях.
Во-первых, чего ты на меня то стрелки переводишь?

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

Цитата:

"проблемы исследования кода" в этой ветке.

"
- А что сказал папа
- Мат пересказывать?
- Нет
- Ну тогда он промолчал"

ок забьем, остаются проблемы переименования - вроде при использовании classStr/methodStr у переименователя есть вся информация о том что надо переименовывать.

Цитата:

пожалуйста, давай в этой ветке обсуждать Framework.

Давай разберем конкретную проблему фреймворка с конкретными примерами кода.

[sukhanchik]

Цитата:

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

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

Вот тут есть одна очень маленькая, но ключевая деталь.
С т.з. оптимизации времени написания кода - любая технология по программированию проигрывает технологии Copy & Paste

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

Все высокие разговоры о том, что код нужно не копировать, а делать единым и потом наследовать разбиваются о жестокую реальность, в которой заказчик не хочет тратить лишнее время на причесывание кода, а разработчики не могут / не хотят (нужное подчеркнуть) заниматься этим причесыванием, ибо незамотивированы (а чем мотивировать, если даже в этой ветке нет явного ответа на вопрос Почему?)

В конце концов - будут или наследники RunBase или контракты или еще какие-то фишки - все сведется к инструкции для начинающего: Откопируй такой-то код и внеси тут изменения сюда и сюда.

[Vadik]

Цитата:

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

Вот тут есть одна очень маленькая, но ключевая деталь.
С т.з. оптимизации времени написания кода - любая технология по программированию проигрывает технологии Copy & Paste

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

Ну так может перед тем как вендора шпынять сесть таки за букварь, хоть и не царское это дело ?

Образец мышления поколения Copy-Paste приведен прекрасный: один раз слажали, в двадцать мест скопировали, через год обнаружили. Чешем репу. Вывод? Очевидный - СИСТЕМА Г###О!

[belugin]

Цитата:

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

Ну т.е. никто никогда не пишет наследника RunBase "с нуля". Все - копируют с уже существующего примера (класса).

...и иногда забывают поменять код
http://en.wikipedia.org/wiki/Copy_and_paste_programming

[DSPIC]

Цитата:

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

может я чего не понимаю?
может, кто-нибудь сможет объяснить: "ЗАЧЕМ они делают это?"

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


может, кто-нибудь может придумать "ПОЧЕМУ человек-программист захочет использовать ЭТОТ фреймворк? в каких сценариях?"

вот, например, runbasebatch имеет очень понятное, простое и человеческое объяснение: разгрузить компьютер пользователя и перенести тяжелую обработку на мощный сервер.
есть более программистское (но все еще понятное) расширение этого объяснения: Заодно и параметры повторения есть, и задачи выполняются поочередно (что снижает вероятность блокировок).

А для этого Фреймворка есть какое-нибудь объяснение на человеческом языке: ЗАЧЕМ?

весь документ я прочитал. introduction перечитал несколько раз.
все равно - нуб и опозорился.

В целом - не только данный фреймфорк вызываеть много вопросов. Я первые пол года бесился, а сейчас порсто пришел к выводу, что аксапту просто убили, пустив в систему армию засранцев, которые все перетоптали. В результате 20 часов тратишь на поиск как сделать что-то, что раньше занимало час\два. Клиентам очень сложно объяснить, почему эта мелочь занимает так много времени.

Цитата:

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

для добавления одного параметра в RunBase надо:

- добавить поле в класс
- добавить поле в макрос со списком полей для упаковки/распаковки
- по хорошему еще:
1. добавить два макроса для новой версии в classdeclaration
2. Добавить в распаковку логику по разделению этих версий
- добавить в создание диалога
- добавить в получение данных из диалога

Для добавления параметра в SysOperationFramework надо

- добавить поле в класс-контракт
- добавить метод-свойство в класс-контракт
- аннотировать метод атрибутами для диалога

... и они очень радуютя подобным нововведениям, и охотно платят за это деньги. И я рад, очень.

[fed]

Я бы главную проблему DAX2012 сформулировал так: Разработчики (в широком смысле) в MS не понимали что их продукт, на проектах, будут переписывать люди, у которых значительно меньше времени и значительно шире специализация чем у сотрудников MS.
Все остальное - лишь проявление этой проблемы...