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

[imir]

Смотрим New_Changed_and_Deprecated_Features_for_Microsoft_Dynamics_AX_2012.pdf

The framework supports the separation of the user interface, contracts, and operations. The framework enables business operations to run synchronously or asynchronously, and provides various methods for invoking business operations. Developers have more flexibility and control.

More flexibility это гуд, но не убедительно - я слышал, есть задумка вынести пакетники из AOS на IIS, плюс заставить их работать как сервисы, короче в runbasebatch это не влезало, а архитектура - provider, controller, data contract сейчас повсеместно пихается.

[mazzy]

Цитата:

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

The framework supports the separation of the user interface, contracts, and operations. The framework enables business operations to run synchronously or asynchronously, and provides various methods for invoking business operations. Developers have more flexibility and control.

Угу. Видели этот маркетинговый булшит.

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

ПОЧЕМУ человек захочет выбирать запускать синхронно или асинхронно? (to run synchronously or asynchronously)
ПОЧЕМУ человек почувствует себя счастливым от того, что у него есть несколько различных методов запуска бизнес-операций? (various methods for invoking business operations)

программирование ради программирования.

[mazzy]

Цитата:

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

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

[sukhanchik]

Цитата:

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

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

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

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

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

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

[Vadik]

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

один раз слажали

а где слажали в старом-добром runbasebatch?

[Logger]

Коллеги, ругаться на MS можно много и долго, но он большой и ему видней. А по факту 2012-я будет такой какая она есть. Разве что в следующей версии поправят что-нить. Может подумать над инструментом, который позволит упростить нужный нам поиск проблемных мест ?

[mazzy]

может подумать над другой системой?

[belugin]

Цитата:

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

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

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

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

Цитата:

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

Code is our enemy

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

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

[belugin]

Цитата:

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

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

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

[Logger]

Цитата:

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

может подумать над другой системой?

Например ?
(выбор невелик)

[mazzy]

Цитата:

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

Например ?
(выбор невелик)

предлагаю открыть новую ветку, если интересно обсудить.

[mazzy]

Цитата:

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

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

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

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

Хм... а можешь ткнуть в страницу мануала из этой ветки и/или привести цитаты из оного?
что-то я не увидел такого. Может плохо прочитал.

[belugin]

Цитата:

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

Хм... а можешь ткнуть в страницу мануала из этой ветки и/или привести цитаты из оного?
что-то я не увидел такого. Может плохо прочитал.

Глава "SysOperation sample: SysOpSampleBasicController"


См табличку:
Dialog Base getFromDialog putToDialog pack unpack | Base functionality implemented by the framework.
run Implemented by the base framework. Handles marshaling execution to a CLR session

Соответственно нет кода, а раз нет кода - нет проблем.

Вообще у меня получился более минималистичный пример:

Контракт

[DataContractAttribute]
class TEST_HelloContract
{
    Name name;
}
[DataMemberAttribute]
public Name parmName(Name _name = name)
{
    name = _name;
    return name;
}

Операция

class TEST_HelloOp
{
}
void sayHello(TEST_HelloContract _contract)
{
    info(strFmt("Hello %1", _contract.parmName()));
}

Запускалка:
\Menu Items\Action\TEST_Hello

• ObjectType: Class
• Object: SysOperationServiceController
• Parameters: TEST_HelloOp.SayHello

И всё - никаких методов main, dialog, pack, unpack, макросов, extendedTypeStr и прочего.

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

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

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

[sukhanchik]

Цитата:

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

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

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

Цитата:

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

...и иногда забывают поменять код

Цитата:

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

Глава "SysOperation sample: SysOpSampleBasicController"
...
Соответственно нет кода, а раз нет кода - нет проблем.
...
И всё - никаких методов main, dialog, pack, unpack, макросов, extendedTypeStr и прочего.
...
А еще плюс, что по умолчанию у нас есть программный интерфейс для операции - никто не мешает вызвать ее из другого кода без модификаций

Я хочу заметить, что я лично не отношусь к тем людям, которые считают методику Copy & Paste лучшей методикой. Но я вижу суровую реальность у:
- внедренцев, когда они "вводят в строй" нового разработчика. А имеется достаточно большой соблазн купить программиста подешевле, но которого надо "вводить в строй", плюс у некоторых внедренцев существует весьма частая ротация кадров, что приводит к постоянному состоянию "ввода в строй" разработчиков.
- клиентов, когда они набирают к себе либо слабых специалистов, либо новичков, но при этом требуют от исполнителя выполнить задачу "здесь и сейчас и быстро".
- аутсорсеров / фрилансеров, у которых есть интерес только в своей задаче и которым неинтересно создание системы классов, какого-то большого и красивого кода. Вплоть до того, что решением задачи может быть джоб с пунктом меню на себя.

Ну т.е. конечно всем на словах понятно - что чем сложнее система - тем больше требуется мозгов, чтобы ее поддерживать или в ней кодить. И конечно это согласуется с политикой Microsoft в том, что АХ переориентируется на систему уровня SAP.

Просто очень хочется отметить слова fed

Цитата:

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

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

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

Цитата:

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

Вывод? Очевидный - СИСТЕМА Г###О!

. Т.е. разработчику нужно дать такой инструмент, применяя который он совершал бы меньше ошибок. Технология Copy & Paste - одна из такого рода инструментов.

Возьмем к примеру пользовательский интерфейс. Его ж кто-то продумывает; есть команда, который этот UI рисует. Вот тут нужно что-то подобное, но для разработчика, чтобы он был мотивирован перейти на новую технологию. Конечно хорошо, когда количество копируемого кода будет меньше. Но при этом в мозгах у разработчика должно быть четкое понимание того, что так будет и так будет проще как писать, так и поддерживать. В частности, поэтому и жуть как полезны перекрестные ссылки.

[EVGL]

О чем копья-то ломаем? Консервативные программисты могут продолжать работать по старинке. Я парочку классов SysOperation сделал, проблем - никаких. Было только сложно передавать внутренние параметры в отчет так, чтобы они не отображались в диалоге, поскольку соответствующий атрибут в системе предусмотрен, но не работает.

Цитата:

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

Так и сделано - контракт продумывает, builderUI - строит.

Цитата:

Т.е. разработчику нужно дать такой инструмент, применяя который он совершал бы меньше ошибок. Технология Copy & Paste - одна из такого рода инструментов.

Неожиданное замечание. Книги по программированию не пробовали писать? Может получиться бестселлер.

[Удвой Покуров]

Цитата:

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

Отсутствующий код не надо читать, не надо разрабатывать, не надо апгрейдить на следующие версии/севиспаки

Прекрасно! Следовательно, идеальной системой является та, которая не содержит код. RunBase, я буду по тебе скучать

[belugin]

Удвой, Идеальный конечный результат

[mazzy]

Цитата:

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

Вообще у меня получился более минималистичный пример:

Ага. Спасибо. Теперь боль-мень понятно что именно добивались.

Хотя твой пример категорически отличается от того, что в книжке.
Кроме того, текст с названием метода в параметре menuItem - это еще один вариант пушного зверька.
Ну, и у меня:
1. нажатие на кнопку Ок приводит к ошибке (скриншот 1)
2. добавление новой переменной в класс-контракт не приводит к появлению нового элемента в диалоге (см. скриншот 2)
3. изменение типа Name на Description не приводит к изменению Label и StatusText (см. скриншот 2)

Подозреваю, что 2 и 3 из-за того, что я нуб и опозорился.
Но пока все равно выглядит примерно так:

вполне возможно, что это я чего-то не понимаю.

[belugin]

IL перегенерил?