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

[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.

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

[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 и прочего.

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

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

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

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

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

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

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

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

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

[Vadik]

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

[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 надо

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

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