AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 10.01.2019, 17:47   #1  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
572 / 374 (14) ++++++
Регистрация: 27.04.2006
Адрес: Montreal
Runbase vs SysOperation
Цитата:
Сообщение от trud Посмотреть сообщение
Добавил еще несколько дополнений:
  • Генерация типового кода для классов RunBase
а runbase разве не был проклят с появлением ангела sysoperation?
__________________
Felix nihil admirari
Старый 10.01.2019, 18:08   #2  
trud is offline
trud
Участник
Лучший по профессии 2017
 
781 / 1029 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от wojzeh Посмотреть сообщение
а runbase разве не был проклят с появлением ангела sysoperation?
Проклят кем?
Идея sysoperation конечно изначальна была хороша, но никто не стал ее развивать. Т.е. сейчас RunBase это единственный способ писать расширяемые классы(с PU22 даже обещают через CoC). Расширения DataContract недоступны. Плюс иногда нужны доп. возможности, к примеру внутри класса управлять задачами, создавая подзадачи
За это сообщение автора поблагодарили: wojzeh (1), Logger (3).
Старый 10.01.2019, 20:30   #3  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
650 / 674 (24) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от wojzeh Посмотреть сообщение
а runbase разве не был проклят с появлением ангела sysoperation?
Это надо в отдельную тему. Все говорят, что его надо использовать потому что он новый, как по мне, аргумент не очень, у вас есть получше?
Старый 11.01.2019, 08:51   #4  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,731 / 2387 (85) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
В 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() в той же сессии.
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 11.01.2019 в 08:54.
За это сообщение автора поблагодарили: Logger (3), trud (5), axotnik88 (1), AlGol (2), alex55 (1).
Старый 11.01.2019, 18:49   #5  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
572 / 374 (14) ++++++
Регистрация: 27.04.2006
Адрес: Montreal
Цитата:
Сообщение от trud Посмотреть сообщение
Проклят кем?
Идея sysoperation конечно изначальна была хороша, но никто не стал ее развивать. Т.е. сейчас RunBase это единственный способ писать расширяемые классы(с PU22 даже обещают через CoC). Расширения DataContract недоступны. Плюс иногда нужны доп. возможности, к примеру внутри класса управлять задачами, создавая подзадачи
спасибо! не знал про это.

и что, в этой связи в d365 всё переделано взад на runbase?
__________________
Felix nihil admirari
Старый 11.01.2019, 19:32   #6  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,845 / 2372 (87) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от trud Посмотреть сообщение
Расширения DataContract недоступны.
Анонсировано, что добавят.
Старый 11.01.2019, 23:41   #7  
wojzeh is offline
wojzeh
Участник
Аватар для wojzeh
Соотечественники
 
572 / 374 (14) ++++++
Регистрация: 27.04.2006
Адрес: Montreal
Цитата:
Сообщение от EVGL Посмотреть сообщение
Анонсировано, что добавят.
и опять выпустят фетву против runbase? нам-то чо делать: крестик снимать или...?
__________________
Felix nihil admirari
Старый 13.01.2019, 20:28   #8  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,592 / 5227 (182) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 2
Мне кажется, подобно тому, как начинающие разработчики в прежних версиях упускали, где (на сервере или на клиенте) в какой момент времени будет выполняться тот или иной метод их наследника 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 в этом плане как-то больше дисциплинирует что ли.

Последний раз редактировалось gl00mie; 13.01.2019 в 20:57.
Старый 13.01.2019, 21:10   #9  
user_ax is offline
user_ax
Участник
Аватар для user_ax
 
589 / 37 (3) +++
Регистрация: 07.10.2012
Адрес: ZP
Цитата:
Сообщение от wojzeh Посмотреть сообщение
и опять выпустят фетву против runbase? нам-то чо делать: крестик снимать или...?
Не думаю, что до этого дойдет.
Расширение контракт классов - хорошее прекимущество, особенно когда закроют полностью app suite.
А то приходится такой велосипед городить чтобы добавить новые атрибуты в sys operation, просто капец.

Не думаю, опять же, что будут хаять опять runBase, если его так прокачали, как описали выше ( новая сессия, что несомненно круто!)
Старый 14.01.2019, 10:04   #10  
trud is offline
trud
Участник
Лучший по профессии 2017
 
781 / 1029 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Для USR-разработчиков, по-моему, SysOperation предпочтительнее, потому что позволяет более четко отделить сервис от контракта и UI для интерактивного ввода параметров, что способствует повторному использованию сервисных операций в тех местах, которые изначально не предполагались.
Вот это как раз непонятно. Вы же помните что unpack контракта у SysOperation происходит неявно в методе new? Т.е. вызывая SysOperation из кода вы вообще рискуете получить случайный набор параметров на входе.
Это на мой взгляд фундаментальный баг, о котором многие забывают(или не знают)
Например первая ссылка по запросу Post purchase order through code Ax2012 выдает следующий фрагмент кода(что отлично работало в 2009, когда класс был наследником от RunBase), который может прекратить работать в любом момент - из за того что юзер под которым это запускается может разнести PO из интерфейса со спец. параметрами(типа проверки кредитного лимита)

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

purchFormLetter = PurchFormLetter::construct(DocumentStatus::PurchaseOrder);
purchFormLetter.update(purchTable, , systemDateGet(), PurchUpdate::All);
}
Старый 14.01.2019, 12:04   #11  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,295 / 2505 (92) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от trud Посмотреть сообщение
Вот это как раз непонятно. Вы же помните что unpack контракта у SysOperation происходит неявно в методе new?
В методе new какого класса он происходит?
Контракт распаковывает контроллер. Который это делает в методе unpack.

Контракт - это такой же класс как и все, просто размеченный атрибутами.
__________________
https://axcoder.github.io
Старый 14.01.2019, 13:36   #12  
trud is offline
trud
Участник
Лучший по профессии 2017
 
781 / 1029 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от belugin Посмотреть сообщение
В методе new какого класса он происходит?
Контракт распаковывает контроллер. Который это делает в методе unpack.
ну да, в контроллере. Для PurchFormLetter это происходит неявно, в методе construct. причем в методе getDataContractObject
Хотя может это и кривизна конкретной реализации PurchFormLetter, но недавно мы много дней потеряли на поиски этой баги, когда у некоторых пользователей подставлялись старые значения при запуске разноски из кода
Я что-то подумал что это баг всего фрамеворка, но возможно стоит еще поизучать вопрос

Нажмите на изображение для увеличения
Название: PFL.png
Просмотров: 204
Размер:	90.5 Кб
ID:	12180

Последний раз редактировалось trud; 14.01.2019 в 13:39.
За это сообщение автора поблагодарили: gl00mie (5).
Старый 14.01.2019, 16:29   #13  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,295 / 2505 (92) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Я думаю, вот эта фраза

Цитата:
способствует повторному использованию сервисных операций в тех местах, которые изначально не предполагались.
относилась к тому, что может просто взять, заполнить контракт самостоятельно и запустить операцию. В случае runBase для этого, надо, чтобы сначала автор кода специально придумал и выставил наружу API
__________________
https://axcoder.github.io
Старый 14.01.2019, 16:41   #14  
trud is offline
trud
Участник
Лучший по профессии 2017
 
781 / 1029 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от belugin Посмотреть сообщение
относилась к тому, что может просто взять, заполнить контракт самостоятельно и запустить операцию. В случае runBase для этого, надо, чтобы сначала автор кода специально придумал и выставил наружу API
А как быть с всякими prePromptModifyContract и подобными методами(иногда в них запихивают бизнес логику)? т.е. это будет работать так же как и runBase где вы заполните все parm методы и вызовете run.
Старый 14.01.2019, 17:13   #15  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,295 / 2505 (92) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от trud Посмотреть сообщение
А как быть с всякими prePromptModifyContract и подобными методами(иногда в них запихивают бизнес логику)? т.е. это будет работать так же как и runBase где вы заполните все parm методы и вызовете run.

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

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

Т.е. если он содержит бизнес-логику. То все равно она должна уходить в контракт и это можно сымитировать
__________________
https://axcoder.github.io
Старый 14.01.2019, 17:53   #16  
trud is offline
trud
Участник
Лучший по профессии 2017
 
781 / 1029 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Обычно там делают заполнение параметров от query или наоборот - query от параметров. query кстати в датаконтракт не входит, т.е. ее дополнительно нужно будет передавать.
ну т.е. о чем я и писал, когда имел ввиду развитие framework - существует множество подобных мелочей, которые никто особо не правит и которые сводят все преимущества впустую. т.е. кода у вас получится в итоге больше, с еще большим дублированием чем RunBase
Старый 14.01.2019, 19:32   #17  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,295 / 2505 (92) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от trud Посмотреть сообщение
query кстати в датаконтракт не входит, т.е. ее дополнительно нужно будет передавать.
Это как? Если в класс/контракт добавить Query parmXXX() или в метод добавить параметр Query xxx оно будет частью контракта?

Вы какую ситуацию имеете ввиду?
__________________
https://axcoder.github.io
Старый 15.01.2019, 01:27   #18  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,592 / 5227 (182) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от 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 вполне себе может быть частью контракта. Или речь про какие-то стандартные контракты, а не "вообще"?..
Старый 15.01.2019, 02:30   #19  
trud is offline
trud
Участник
Лучший по профессии 2017
 
781 / 1029 (36) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Я, может, как-то не так готовлю SysOperation framework, но при необходимости я не гнушаюсь добавлять в DataContract параметры типа Query. Или речь про какие-то стандартные контракты, а не "вообще"?..
Ну мы обсуждаем операции, для которых есть диалог пользователя(обычный режим запуска), плюс возможность эту же операцию запустить из кода. Разве если вы добавите в DataContract parmQuery, этот Query появится в диалоге в интерактивном режиме запуска?
Старый 15.01.2019, 09:08   #20  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,295 / 2505 (92) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Записей в блоге: 5
Цитата:
Сообщение от trud Посмотреть сообщение
Ну мы обсуждаем операции, для которых есть диалог пользователя(обычный режим запуска), плюс возможность эту же операцию запустить из кода. Разве если вы добавите в DataContract parmQuery, этот Query появится в диалоге в интерактивном режиме запуска?
Да.
__________________
https://axcoder.github.io
Теги
runbase, sysoperation framework

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
stoneridgesoftware: Batch Processing in Dynamics AX 2012 Using SysOperation Framework Blog bot DAX Blogs 0 28.03.2017 00:11
emeadaxsupport: Update to AX 2012 Framework Component Documentation: SysOperation Framework Blog bot DAX Blogs 0 09.06.2012 00:11
daxmusings: From RunBase to SysOperation : Business Operation Framework (Cont'd) Blog bot DAX Blogs 0 19.08.2011 16:11
daxmusings: From RunBase to SysOperation : Business Operation Framework Blog bot DAX Blogs 4 17.08.2011 16:01
Inside Dynamics AX 4.0: RunBase Framework Extension Part IV Blog bot DAX Blogs 0 02.10.2007 04:49
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 13:41.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.