Runbase vs SysOperation

[wojzeh]

Цитата:

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

Добавил еще несколько дополнений:

• Генерация типового кода для классов RunBase

а runbase разве не был проклят с появлением ангела sysoperation?

[trud]

Цитата:

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

а runbase разве не был проклят с появлением ангела sysoperation?

Проклят кем?
Идея sysoperation конечно изначальна была хороша, но никто не стал ее развивать. Т.е. сейчас RunBase это единственный способ писать расширяемые классы(с PU22 даже обещают через CoC). Расширения DataContract недоступны. Плюс иногда нужны доп. возможности, к примеру внутри класса управлять задачами, создавая подзадачи

[skuull]

Цитата:

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

а runbase разве не был проклят с появлением ангела sysoperation?

Это надо в отдельную тему. Все говорят, что его надо использовать потому что он новый, как по мне, аргумент не очень, у вас есть получше?

[sukhanchik]

В AX 2012 Runbase был действительно объявлен устаревшим:
https://docs.microsoft.com/en-us/dyn...base-framework

Однако в D365FO его исключили из "санкционного списка":
https://docs.microsoft.com/en-us/dyn...eprecated-apis

И даже наоборот, появилась статья, как расширять наследников RunBase:
https://docs.microsoft.com/en-us/dyn...-runbase-class

Так что он не только не убран, но и "в расцвете сил". По большому счету в него добавили то, чем был силен SysOperation - а именно запуском в отдельной сессии исполнения бизнес-логики (вспоминаем, как отдельно, не вешая клиента, грузятся SSRS-отчеты в АХ2012). Т.о. теперь в методе main мы вызываем не метод run(), а метод runOperation(), который в свою очередь запускает метод run() либо в отдельной сессии (поведение по умолчанию), либо, если перекрыт метод canRunInNewSession(), который возвращает false - то тогда запускает метод run() в той же сессии.

[wojzeh]

Цитата:

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

Проклят кем?
Идея sysoperation конечно изначальна была хороша, но никто не стал ее развивать. Т.е. сейчас RunBase это единственный способ писать расширяемые классы(с PU22 даже обещают через CoC). Расширения DataContract недоступны. Плюс иногда нужны доп. возможности, к примеру внутри класса управлять задачами, создавая подзадачи

спасибо! не знал про это.

и что, в этой связи в d365 всё переделано взад на runbase?

[EVGL]

Цитата:

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

Расширения DataContract недоступны.

Анонсировано, что добавят.

[wojzeh]

Цитата:

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

Анонсировано, что добавят.

и опять выпустят фетву против runbase? нам-то чо делать: крестик снимать или...?

[gl00mie]

Мне кажется, подобно тому, как начинающие разработчики в прежних версиях упускали, где (на сервере или на клиенте) в какой момент времени будет выполняться тот или иной метод их наследника RunBase, сейчас дискутирующие упускают то, кто будет писать исходный класс на основе SysOperation или RunBase - и кто потом будет его расширять Наверно, стоит ввести некую классификацию разработчиков в данном контексте:

• SYS-разработчики (условно) - разработчики стандартного приложения
• ISV-разработчики вертикальных решений, устанавливаемых на нескольких внедрениях
• USR-разработчики (условно) - авторы модификаций на тех или иных конкретных проектах внедрения

В разрезе такой классификации чисто комбинаторно можно выделить такие сценарии:

1. SYS-код кастомизируется ISV-разработчиком
2. SYS-код кастомизируется USR-разработчиком
3. ISV-код кастомизируется USR-разработчиком
4. ISV-код кастомизируется ISV-разработчиком, разрабатывающим свое сторонее ISV-решение, которое должно уметь устанавливаться вместе с другим ISV-решением.
5. USR-код кастомизируется USR-разработчиком

Возможности менять код через расширения интересны, по-моему, в сценариях 1, 2 и 3, причем в сценарии 3 - при условии, что ISV-модель закрыта для overlaying'а. В то же время, ISV-решения зачастую поставляются с исходниками и при этом не закрыты для overlaying-а. Сценарий 4 - это какая-то экзотика, как мне кажется; если же есть два ISV-решения одной и той же компании, то там можно придумать более естественные возможности кастомизаций: всякие там события-делегаты, интерфейсы + inversion of control и прочая. Использование расширений в сценарии 5 мне лично кажется не очень естественным: не понятно, зачем так поступать в реальной жизни.

Цитата:

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

Идея sysoperation конечно изначальна была хороша, но никто не стал ее развивать.

Развивать в сторону чего, возможности использовать механизмы расширений?

Цитата:

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

Сейчас RunBase это единственный способ писать расширяемые классы(с PU22 даже обещают через CoC). Расширения DataContract недоступны. Плюс иногда нужны доп. возможности, к примеру внутри класса управлять задачами, создавая подзадачи

Полагаю, эти утверждения сделаны с позиции ISV-разработчика, который желает закрыть свой код от overlaying'а для USR-разработчиков SYS-разработчики вряд ли принимают во внимание такие нюансы, а USR-разработчикам без разницы, потому что свой собственный код или код коллег им нет надобности менять через extension-ы. Мне, например, как выступающему в роли USR-разработчика SysOperation в моих собственных модификациях более симпатичен и удобен, нежели RunBase. Но при этом от SYS- и ISV-разработчиков, я, наверно, ожидал бы скорее использования RunBase, чтоб у меня было больше возможностей при создании расширений

Цитата:

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

и опять выпустят фетву против runbase? нам-то чо делать: крестик снимать или...?

Рассуждения про выбор между SysOperation и RunBase, как показано выше, существенно зависят от того, в какой роли вы выступаете (SYS/ISV/USR-разработчик) и про чей код говорите: свой или чужой, т.е. от сценария (1-5), в контексте которого идет обсуждение Для USR-разработчиков, по-моему, SysOperation предпочтительнее, потому что позволяет более четко отделить сервис от контракта и UI для интерактивного ввода параметров, что способствует повторному использованию сервисных операций в тех местах, которые изначально не предполагались. Наследников RunBase обычно использовать из стороннего кода менее удобно, потому что там часто не выделен четко контракт (банально не хватает parm-методов), плюс внутри могут быть какие-то неявные завязки на интерактивный запуск, скажем, инициализация по глобальным настройкам и т.п. SysOperation в этом плане как-то больше дисциплинирует что ли.

[user_ax]

Цитата:

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

и опять выпустят фетву против runbase? нам-то чо делать: крестик снимать или...?

Не думаю, что до этого дойдет.
Расширение контракт классов - хорошее прекимущество, особенно когда закроют полностью app suite.
А то приходится такой велосипед городить чтобы добавить новые атрибуты в sys operation, просто капец.

Не думаю, опять же, что будут хаять опять runBase, если его так прокачали, как описали выше ( новая сессия, что несомненно круто!)

[trud]

Цитата:

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

Для USR-разработчиков, по-моему, SysOperation предпочтительнее, потому что позволяет более четко отделить сервис от контракта и UI для интерактивного ввода параметров, что способствует повторному использованию сервисных операций в тех местах, которые изначально не предполагались.

Вот это как раз непонятно. Вы же помните что unpack контракта у SysOperation происходит неявно в методе new? Т.е. вызывая SysOperation из кода вы вообще рискуете получить случайный набор параметров на входе.
Это на мой взгляд фундаментальный баг, о котором многие забывают(или не знают)
Например первая ссылка по запросу Post purchase order through code Ax2012 выдает следующий фрагмент кода(что отлично работало в 2009, когда класс был наследником от RunBase), который может прекратить работать в любом момент - из за того что юзер под которым это запускается может разнести PO из интерфейса со спец. параметрами(типа проверки кредитного лимита)

static void postPurchaseOrder(Args _args)
{
PurchTable purchTable = PurchTable::find();
PurchFormLetter purchFormLetter;

purchFormLetter = PurchFormLetter::construct(DocumentStatus::PurchaseOrder);
purchFormLetter.update(purchTable, , systemDateGet(), PurchUpdate::All);
}

[belugin]

Цитата:

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

Вот это как раз непонятно. Вы же помните что unpack контракта у SysOperation происходит неявно в методе new?

В методе new какого класса он происходит?
Контракт распаковывает контроллер. Который это делает в методе unpack.

Контракт - это такой же класс как и все, просто размеченный атрибутами.

[trud]

Цитата:

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

В методе new какого класса он происходит?
Контракт распаковывает контроллер. Который это делает в методе unpack.

ну да, в контроллере. Для PurchFormLetter это происходит неявно, в методе construct. причем в методе getDataContractObject
Хотя может это и кривизна конкретной реализации PurchFormLetter, но недавно мы много дней потеряли на поиски этой баги, когда у некоторых пользователей подставлялись старые значения при запуске разноски из кода
Я что-то подумал что это баг всего фрамеворка, но возможно стоит еще поизучать вопрос

[belugin]

Я думаю, вот эта фраза

Цитата:

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

относилась к тому, что может просто взять, заполнить контракт самостоятельно и запустить операцию. В случае runBase для этого, надо, чтобы сначала автор кода специально придумал и выставил наружу API

[trud]

Цитата:

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

относилась к тому, что может просто взять, заполнить контракт самостоятельно и запустить операцию. В случае runBase для этого, надо, чтобы сначала автор кода специально придумал и выставил наружу API

А как быть с всякими prePromptModifyContract и подобными методами(иногда в них запихивают бизнес логику)? т.е. это будет работать так же как и runBase где вы заполните все parm методы и вызовете run.

[belugin]

Цитата:

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

А как быть с всякими prePromptModifyContract и подобными методами(иногда в них запихивают бизнес логику)? т.е. это будет работать так же как и runBase где вы заполните все parm методы и вызовете run.

Смысл этого метода чисто в UI.

Provides the opportunity to modify the contract before the dialog is shown to the user.

Т.е. если он содержит бизнес-логику. То все равно она должна уходить в контракт и это можно сымитировать

[trud]

Обычно там делают заполнение параметров от query или наоборот - query от параметров. query кстати в датаконтракт не входит, т.е. ее дополнительно нужно будет передавать.
ну т.е. о чем я и писал, когда имел ввиду развитие framework - существует множество подобных мелочей, которые никто особо не правит и которые сводят все преимущества впустую. т.е. кода у вас получится в итоге больше, с еще большим дублированием чем RunBase

[belugin]

Цитата:

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

query кстати в датаконтракт не входит, т.е. ее дополнительно нужно будет передавать.

Это как? Если в класс/контракт добавить Query parmXXX() или в метод добавить параметр Query xxx оно будет частью контракта?

Вы какую ситуацию имеете ввиду?

[gl00mie]

Цитата:

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

Я думаю, вот эта фраза относилась к тому, что может просто взять, заполнить контракт самостоятельно и запустить операцию. В случае runBase для этого, надо, чтобы сначала автор кода специально придумал и выставил наружу API

Именно так.

Цитата:

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

ну да, в контроллере. Для PurchFormLetter это происходит неявно, в методе construct. причем в методе getDataContractObject
Хотя может это и кривизна конкретной реализации PurchFormLetter, но недавно мы много дней потеряли на поиски этой баги, когда у некоторых пользователей подставлялись старые значения при запуске разноски из кода

Мда, занятно... для прошлых версий, когда создавались наследники RunBase, было хорошим тоном делать для них статический construct(), где после new() еще вызывать getLast(). Смысл был в том, чтобы в стороннем коде можно было дернуть construct(), получить экземпляр класса и при необходимости спокойной выполнять дополнительную инициализацию его через parm-методы, не боясь, что внутри prompt() он все ваши труды перезатрет из SysLastValue. Возможно, разработчики PurchFormLetter в 12-ке решили пойти схожим путем - хотели, как лучше...

Цитата:

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

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

Я, может, как-то не так готовлю SysOperation framework, но при необходимости я не гнушаюсь добавлять в DataContract параметры типа Query. Да, при этом нужно делать дополнительную валидацию контракта на предмет передачи "кривого" Query, в котором отсутствуют ожидаемые DataSource'ы. Да, при этом нужно делать некий метод, создающий "Query по умолчанию" - либо в контракте, либо в сервисе. Да, такой вариант в AX 2012 не подходит для сервисов, вызываемых через AIF по http, потому что там DataContract должен быть вообще без малейшей бизнес-логики и ссылок на посторонние типы и классы (хотя это - скорее "особенности" публикации AIF'ом сервисов на IIS). Но в целом, если нужно создать сервис, принимающий на вход Query и запускаемый пользователем интерактивно, а не извне через http, по-моему, Query вполне себе может быть частью контракта. Или речь про какие-то стандартные контракты, а не "вообще"?..

[trud]

Цитата:

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

Я, может, как-то не так готовлю SysOperation framework, но при необходимости я не гнушаюсь добавлять в DataContract параметры типа Query. Или речь про какие-то стандартные контракты, а не "вообще"?..

Ну мы обсуждаем операции, для которых есть диалог пользователя(обычный режим запуска), плюс возможность эту же операцию запустить из кода. Разве если вы добавите в DataContract parmQuery, этот Query появится в диалоге в интерактивном режиме запуска?

[belugin]

Цитата:

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

Ну мы обсуждаем операции, для которых есть диалог пользователя(обычный режим запуска), плюс возможность эту же операцию запустить из кода. Разве если вы добавите в DataContract parmQuery, этот Query появится в диалоге в интерактивном режиме запуска?

Да.